Ten Years of Framework Design Guidelines: Video Podcast Transcript
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Welcome to OnMicrosoft—conversations with thought leaders in Microsoft technologies. In this session, Brad Abrams and Krzysztof Cwalina provide a sneak peek at their PDC presentation on framework design guidelines. Learn key lessons from 10 years of framework design.
Brad Abrams: Hello! Welcome. I'm Brad Abrams, an employee at Microsoft. We're at the Redmond campus, and I'm joined by Krzysztof Cwalina. Krzysztof, we're doing a talk at the PDC. (We just found out about this last week, actually, so we've been working hard to finalize things for the talk.) [Meanwhile,] it's 2008, and about 10 years ago you and I started working on the very first draft of [our book] Framework Design Guidelines.
Krzysztof: Yeah, I cannot imagine that it has been 10 years.
Brad: We debated lots of things back in the day. We had this living Word document that went through rounds and rounds of reviews—and, of course, tons and tons of additions—and then it eventually became a book that I'm very proud of. And now we're doing [the second] edition. [Cwalina and Abrams published Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Second Edition in October 2008. -ed.]
But it's good to look back from the year 2008 and just think about what's changed over the last 10 years—how things have either changed or not changed with the guidelines. While I definitely think we've learned—I personally have learned—a lot over the last 10 years, I'm equally impressed by what hasn't changed—certainly, some of the key fundamental tenets of the guidelines. I think we talked early on about "usage first" design—rather than design with a UML model, design with sample code in mind. That has stayed the same. Are there other things you think have stayed the same?
Krzysztof: I think the concepts of simplicity, layering—kind of factoring the framework the right way.
Brad: Yep.
Krzysztof: What changed? We learned a lot about how to explain the design of large framework libraries.
Brad: I think that's true. One of the things that we were talking a lot about in 1998 was properties versus methods. When we first designed the CLR [Common Language Runtime], we didn't have properties at all—all we had was methods. We actually built the first version of the BCL [Base Class Library] and large parts of the framework—Windows Forms and parts of ASP.NET—without any properties whatsoever. So when we made the move to having properties supported in the type system (this is well before we shipped 1.0), we had to think really hard about when to use methods and when to use properties. From a geeky low-level CLR there's no [real] difference between properties and methods—they both resolve to the same IL call that invokes the method. We had to think about what's the developer semantic and what's the meaning. And I think where we landed is about methods being action-oriented (taking some operation—doing some transformation, for example) and properties being a lot more about (at least logically) just exposing data, getting and setting data, and properties shouldn't do a lot more than that.
Krzysztof: Definitely. We were talking a lot about the concept of component-oriented programming or design, where components are basically things that have constructors, properties, methods, and events. This list of four constitutes the underlining of framework design.
Brad: That's right, the PME [Properties, Methods, and Events model].
Krzysztof: Exactly. Finding ourselves in 2008, we have a new concept of extension methods. And when we started to think about how they impact the framework design, we discovered that they actually will have enormous impact on the design. They sound like they're just methods but—
Brad: Describe what extension methods are, just to make sure [that our audience understands].
Krzysztof: Extension methods are basically static methods that you can call with syntax that [makes them] look as if they were instance methods. So basically it's very easy to declare an extension method; it's just a static method with the first parameter being annotated with the modifier called this. As I said, extension methods sound like they are just methods; you may think they are just static methods with some modifier, but they actually fundamentally change the design of the framework. For example, some of the things that you can do with them: You can have implementation in interfaces—or, at least, the system appears as if interfaces had an implementation. And, for example, they are used extensively in LINQ. Because of extension methods and their property that I was just talking about, every single type that implements IEnumerable(Of T), the interface, can gain new capabilities.
Brad: Even ones that were implemented long ago now automatically have IQueryable.
Krzysztof: Exactly, exactly. Another very game-changing property of extension methods is that we always had the tradeoff between componentization and dependencies and usability. So if you wanted to have a component that was very usable, it was nice if the component was able to do quite complex and high-level scenarios. This is the mental model of the many developers who program real business problems. With regular methods, we basically had to put all the functionality related to the business problem on the type that was implemented in methods, which meant that there was a lot of coupling between different parts of the framework. You didn't want to compose your program for very small building blocks—you wanted to have the components that some people called "Swiss Army knives": They do a lot of things, and that's very usable—that's great for high-level programming.
Brad: Yeah, yeah.
Krzysztof: Unfortunately, it's not so good for decoupling parts of the framework. Extension methods allow you to get both usability and decoupling, and the reason is that a method that appears as if it were on the component foo could actually been in a completely different place—because it's just a static method.
Brad: Yep, yep, I love it. And I think that the other great benefit for extension methods is, especially as a user of a framework, you're no longer locked into exactly the decisions that that framework author made. So, for example, if you really want a reverse method on string, you can go write one and have it appear as on string.
Krzysztof: But, as we sometimes say, with power comes responsibility, because extension methods now allow anybody to add a random method to system.string.
Brad: Even though we spent hours and hours designing system.string, now anyone can go and mess with our design.
[Both laugh.]
Krzysztof: Exactly. So that's a big part of the design guidelines for extension methods—talking about both the powers that they offer and the responsibility of people using extension methods not doing things like adding random methods to system.string.
Brad: Totally. Another thing, if I roll back to 1998, the kinds of things we were thinking about: the whole idea of managed code, specifically having managed memory with a garbage collector and a just-in-time compiler really controlling the memory allocation in your program. That was a foreign concept. Certainly other systems [were] going on, but really a lot of the internal developers as well as some of our initial external customers weren't sure that they were willing to trust a sensitive thing like memory allocation and deallocation to the system.
Krzysztof: Yeah.
Brad: Could the garbage collector ever do a good enough job? One of the things that we were thinking about at the time is how you design APIs in a world where there is garbage collection—where usually there [are] not memory ownership issues, as you have with C and C++ APIs. And then, of course, dealing with the realities of some of the resources not being directly managed by the garbage collector; for example, file handles and window handles. How do you build frameworks that work well in that environment? In some intuitive sense, you don't lose the management benefits you get with the garbage collector, but you're able to get rid of those database connections in good time.
Krzysztof: Yeah, yeah, definitely. I remember talking to developers and customers about the .NET Framework 10 years ago, and there were lots of questions about the GC [garbage collector]; ranging from, "Is it ready? Is it primetime for GCs?" to what you mentioned, "How do I manage other things than memory? Is GC for [those things]?" and so on, and so on. Right now, I don't get these questions anymore. When was the last question someone asked you about [that]?
Brad: It has been a while. In fact, I had to scratch my head a little bit. But I used to be really good at answering them, because they used to come up all the time.
Krzysztof: Yeah, exactly. Now, if I had to say what is the one of the most common questions that is not "practical," but [rather] a "big" question, [I would say that it's] how a new technology will impact framework design. I think most often people ask me about concurrency threading. What are we going to be doing with the multiple colors that are showing up?
Brad: That is definitely the 2008 year equivalence: concurrency.
Krzysztof: Yeah, exactly. So, we are making big investments in the .NET Framework in terms of features, and thinking about how we can make multithreaded programming as easy as memory management was made by introduction of the GC—where you don't have to worry about the majority of the tasks related to multithreading.
Brad: It strikes me that it's the same kind of thing; we are essentially adding a layer of abstraction. That's what the garbage collector does when you use the new operator in C#: You're building on a layer of abstraction, and expressing more of your intent in the program, rather than the actual operation. It strikes me that that's the same solution—we're working on different models, but that's basically the solution for concurrency—have developers express their intent. Their intent is that this chunk of code run, and do that in a way that then the system can go figure out how many threads to put that on, based on the hardware on the machine, and how to synchronize things and whatnot.
Krzysztof: I think this will be a multilevel approach, ranging from: 1) making the current explicit threading much easier—because more developers will have to be doing this—to something where developers, as you said, express the intent, and [then] the framework, the system, worries about the details; 2) multithreading that is completely automatic, where the developers don't have to think about multithreading. A good example of this approach is ASP.NET.
Brad: Yeah, I totally agree.
Krzysztof: Most ASP.NET applications—or [rather] all ASP.NET applications—are multithreaded. Developers don't have to think about threading that way.
Brad: We're able to kind of encapsulate that in the ASP.NET programming model.
Krzysztof: Exactly.
Brad: Yeah.
Krzysztof: So now the challenge is how we take it from basically ASP.NET space and kind of expose it broadly, or use it broadly in the .NET Framework.
Brad: That makes lot of sense. So, then, if I go back again and think about 1998, what was going on there, we were working on C# and VB.NET at the time, but we were also thinking about how the CLR was really a common language runtime, and that this runtime would work with a wide range of languages. I remember buying COBOL books at that time, Perl books, and ADA [books], and having the chance to really delve into what these language features had—what was unique about them, what was the same. There were two levels of that problem. One level is just, could we build a CLR that would technically run those languages? All things being equal, that was the easier problem.
The harder problem was that then we needed to go build out a framework that would work with all the languages. If one language didn't support properties and another language did, does that mean that you're not gonna have properties in the system? What if one language supports exceptions and another language doesn't? What is the subset of all the language features that you're able to use in a framework design? We didn't want it to be the case that basically we would bottom out on that being whatever VB does, or whatever C# does. We wanted to have a more deliberate approach, and think about a design that would work for all languages. So that's where the Common Language Specification was born, the CLS, that we later standardized via the ECMA and ISO standardization process that really kind of encapsulated how all the languages would work with the framework.
Krzysztof: That was one of the things that really attracted me to the CLR and .NET Framework, because I was fresh out of school in 1998 and I remember doing projects in some exotic languages at school.
Brad: Yeah, yeah.
Krzysztof: There was always the problem that, yes, you have the compiler, but you don't have the whole ecosystem that is required to do some of the interesting things that I wanted to do—ranging from the development environments to, for example, forms framework. Yes, you could write an engine, [a] theorem prover, in ML; but then actually presenting a user interface was really challenging. So, the Common Language Specification and Common Language Runtime enabled some of the more exotic languages to actually plug into the ecosystem of tools in the .NET Framework. But I think they were still kind of treated as exotic languages. They were not used very broadly in the industry. Now, in 2008, this is changing. I think the industry is maturing to look at the broader language space and see [whether] some of the languages that used to be considered as exotic are actually more suitable for solving real business problems—that includes functional languages like F# and dynamic languages like Python, Ruby, and so on.
Brad: Yeah, absolutely. One could argue that the CLS and the broad framework we did 10 years ago planted the seeds that only now are we beginning to reap in 2008—having a plethora of languages that can plug into the framework, and we'll take advantage of that.
Thanks, Krzysztof. It has been great to think about how things have changed from 1998 to 2008. What do you say we get back together again 10 years from now, and see what's changed in 2018?
Krzysztof: Yeah, I cannot imagine.
Brad: Great—we'll see you then.
For more information, visit onpodcastweekly.com and subscribe to all our podcasts. Brought to you by the publishing imprints and information portal of Pearson Education.