As Microsoft's all important VB 2005 development software tools move closer to formal release, there is anticipation that this version will come closer to supporting traditional VB-style rapid application development than its predecessor did. Individual functions such as My.Space are important. But the overall feel of the .NET framework has been improved to great effect, and many of the improvements here are aimed at VB developers.
Clearly, a look inside Microsoft's thinking on framework design is welcome. Such a view comes now via Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams (Addison-Wesley, 2005). While this book may arise out of efforts inside Microsoft to formalize approaches to creating .NET framework architecture, a glance at the flock of people scooping up copies of the book at last month's PDC05 showed that developers too feel they can benefit from looking inside a framework.
In fact, this book is a significant addition to the literature on software development. We were glad to speak recently with author Krzysztof Cwalina, and, naturally, our thoughts turned to VB. We asked how .NET Framework improvements were aimed at Visual Basic developers.
VB had a huge influence on the guidelines of the Framework, Cwalina replied. "The main difficulty for programmers is that frameworks are vast and, if are not designed carefully, they don't give any indication of where you should start and where you should go next. The strength of VB was that it told you very explicitly which are the important APIs," he said.
"The common scenario APIs were right there in your face. As you moved to the more advanced APIs, they were not so 'in your face,'" Cwalina said.
The .NET 2.0. Framework has tried to improve things for VB developers, especially those who are moving from VB 6.0 to VB.NET 2.0.
"The high-level concept is that the core of the framework covers 80% of scenarios. The plan is not to put the other 20% in the face of the developers immediately when they start to work with the framework," Cwalina said.
To the extent that they can be characterized, VB developers are a pragmatic sort, almost impatient to get working on the task at hand, and not in the thrall of technical virtuosity that sometimes marks a C++ or a dyed-in the-wool object developer. Yet Framework Design Guidelines should intrigue VB developers. A clear view on .NET thinking can only help in day-to-day efforts.
Through to VB 6, the VB developer had a tool that supported quick development. Take a look at the new version of the framework and see if it doesn't take a few steps toward making VB a top citizen in the .NET world.
More of our interview with Framework Design Guidelines author Krzysztof Cwalina
SVB: Can you give us a picture of the art of framework design?
KC: I think that one of the main problems with frameworks is that they are huge; they contain lots of APIs. Developers can use these APIs efficiently only if they don't have to relearn concepts every time they move from one of these APIs to another.
You may create a GUI, then you may do some messaging with the Windows Communication Foundation. You don't want to have to relearn, for example, how to handle events when you switch what you are working on.Things should be consistent across the framework.
A good rule is: If you learn one part of the framework you should in effect know 80% of the rest of the framework. An analogy we use is the rental car. When you get in a rental car, you don't want to have to read the manual to operate the car.
SVB: Can you discuss Framework Design Guidelines as it relates to programmers?
KC: I think the book is equally useful to people you design frameworks and to the people that use the frameworks. If I know some of the "why" behind the design of the framework, I know better how to use this framework. For example, [in the .NET framework], if something is an expensive operation, it should not be a property, it should be a method. If I know that and I see a property, I immediately see that it is not that expensive to call it. I you didn't know the guidelines you might not know that.
SVB: How do design patterns often discussed in object-oriented circles relate to framework design?
KC: The Design Patterns community has concentrated on internal implementations, while the .NET Framework design guidelines originators have focused on the public surface of framework APIs. But there are similarities.
Both traditional design patterns and our framework design guidelines contribute to establish a common design language. Now, people have a common language. I think our guidelines continue [the work of design patterns] in the API space. For example, if I hear or read "Async Pattern," I know how it works, because there is a common language and consistency to the framework.
Related
Framework Design Guidelines page – Addison-Wesley Pearson Education site [Includes TOC, and sample chapters]
