Book Review: Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams.

I've just finished reading Framework Design Guidelines. This book evolved from the design guidelines put together during the development of the .net framework. Both of the authors are program managers on the CLR and .net teams, so you get a great inside look at the thinking behind design decisions made during the development of the base class library. The book is peppered with little side bars where various Microsoft developers comment on the guidelines. These really help to bring the whole thing to life and you get an insight into the arguments that must have gone on over the pros and cons of different approaches. Like they say, designing a good reusable framework is hard and Microsoft have learnt from their past mistakes (did someone say MFC?). I really liked the initial discussion on general framework design where the authors describe how the .net team tried to juggle some of the conflicting requirements that any framework faces; how to keep it simple while providing a powerful tool; how to keep it as open as possible for future enhancements and how to keep it consistent. Having some of the design decisions around some of the best known components laid out in front of you really helps when it comes to understanding and using them. One thing I hadn’t really appreciated, but is obvious when it’s pointed out, is how the framework tries to juggle simplicity with power by using aggregate components for the common simple tasks that offer a façade over a more complex factored API. The book uses the System.IO namespace as an example where the File class provides the high level, easy to use abstraction while the stream classes provide the powerful API needed for more demanding tasks. Of course knowing this is great when you're using .net every day but it's also a real education in how to design good frameworks. Now, you might say, I'm an application developer, not a framework developer so why would I need to know this? But, as Martin Fowler says, following good OO design principles inevitably means that you are constantly designing frameworks, even if you're your only customer. Having said that, one of the best points for me in the book was the discussion on when you shouldn't stick strictly to OO principles, especially when designing components for visual tools to use. Although the book doesn’t once mention test driven development, it did reinforce my love of this way of developing by showing how you should always design from usage scenarios. Always write down how your API is going to be used first. I skimmed a lot of the stuff on naming conventions. If like me you’ve worked in several different enterprises on several different large systems, you’ll have probably discussed naming conventions until you’ve gone slightly silly in the head. But you’ve got to have them and I guess having them here in this book does give you something to point at the next time someone who’s been hiding in a hole for ten years suggests Hungarian. Chapter 7 on exceptions should be required reading for any .net developer. It's the best explanation of why you should use structured exception handling I've yet seen. I wish I'd had this book handy a couple of years ago when I spent hours arguing with an old school developer about the problems with error code return values. Chapter 9 on common design patterns should also be essential reading especially the discussion on the Dispose pattern. The documentation on this in MSDN isn't very good. It stipulates what you should do, but not why you should do it and it's probably why so few developers implement it properly, and that includes me. The authors give an excellent discussion on why should use IDisposable and how you should implement it so there’s no excuse for me doing it incorrectly from now on. So, yes, I really enjoyed this book. It's well designed and written and it works well on two levels, firstly you get an insight into the .net framework, but also it’s a great general good .net practices book. Also it’s well worth checking out Brad Abrams blog.