Book Review: Framework Design Guidelines
My Review: 



(Must Read)
Abrams and Cwalina deliver a set of best practices for designing easy to use frameworks while ensuring consistency with Microsoft's .NET Base Class Library.
The Good | The Bad |
| Provides clear direction; based on real-world examples; includes author/reviewer comments; discusses mistakes made by Microsoft; includes design pattern discussion; included DVD contains videos, sample API spec, and TxRef utility. | More of a reference book; format may be unappealing to some; examples are only in C#. |
As the proud owner of The C# Programming Language, .NET Framework Standard Library Annotated Reference, Volume 1, and The Common Language Infrastructure Annotated Standard, I've read (okay browsed) my share of dry books in the .NET Development Series. (Mind you, many of the others in the series are part of my collection, but didn't *earn* the "dry" comment.) So when I picked up my copy of Framework Design Guidelines, I wasn't sure what to expect. As it turns out, I was extremely pleased to find the right balance of clear guidance and anecdotal evidence for why I should DO or CONSIDER or AVOID or DON'T something. You see, that's the format, which may or may not be your cup of tea. Personally, I like that the authors have painted clear black and white areas (do/don't), without forgetting the grays (consider/avoid). Of course, through comments, they point out some examples when it's also okay to "do" something that's explicitly listed as a "don't". Confused? Hopefully not.
While the last seven chapters discuss guidelines related to Naming, Type Design, Member Design, Extensibility, Exceptions, Usage, and Design Patterns, in the first two chapters, Abrams and Cwalina touch on over-arching framework guidelines. These are the best thirty-one pages of the book (IMHO). Here we read that a well-designed framework is simple, expensive to design, full of trade-offs, borrows from the past, designed to evolve, integrated and consistent. A key take-away from chapter two is the Principle of Scenario-Driven Design. Rather than beginning with the object model and then finding a way to get key scenarios to work, the authors recommend the reverse. Start by writing how the code should look for those scenarios, then fill in the details.
Finally, it would be a mistake to forget the content that's included on the DVD. In addition to a link to the most recent version of FxCop, and a sample API specification document, you get almost ten hours of video footage of the authors (and a couple other guys) presenting much of the information contained within the book. Lastly, they've included an extra goodie, TxRef. This little application, source included, allows you to generate a simple "C# header file view" of an API useful for reviews. While there is a defect in the source code, the fix is straightforward and available here.
As a member of the Community Server development team, I'm looking forward to embracing this guidance as we enhance our APIs into a framework that's easy to use, understand, and extend.