Becket said
I haven't purchased this book yet, but the DVD that it comes with has been made available for free by the publisher through the Internet.
I can't provide the link here (because of Amazon review guidelines) but if you go to Google and type in "framework design guidelines extra content", you won't have problems finding the download link.
Igor Guerrero said
Also if you're thinking on developing a framework on any Object Oriented language, this is your book, it covers all the guidelines that makes a framework usable and powerful.
Idei Csaba said
Good to see the way how they created the framework, what makes them to apply these rules and patterns. This book expanded my .net world and I was pondering over the design many times.
Jason Short said
I build a product for users that has a large and complicated API. Over the years the API has grown sort of as the users needed it, and as the developers working on it thought of things. As a result you end up with one designers version of a variable called IsSet and another in another class called Active. The little things in an API (like consistent naming) make a big difference to users. So I was interested when I saw this book was from the Dot Net team.
The book is a series of guidelines, and then callouts from various contributors to the framework of why they like or dislike the rule. And in some cases very frank revelations about where they broke the rule and have now come to regret it. I like that format as most of the authors seemed to be very willing to discuss the frameworks mess ups and not just point to the parts they got right. It makes it seem much more human and approachable to me now.
There is not a lot of examples in the book though, it is mostly about building a style and set of guidelines for your application framework. I think this would make a great read for entry level programmers to help them understand the why you don't allow them to change the way things are exposed publicly, or to programmers who are looking to start designing APIs and are just looking for guidance. It is not a concrete how to build an API for doing "sometask". It is all about the theory behind API design and why you should employ the rules.
I have experienced many of the pains they explain in the book first hand (especially about Interfaces). Wish I would have read it before I released the first version of our API. I am implementing some changes based upon what I have read here, so it is definately a worthy book for those looking to take their design skills a little further.
Melvin W. Grubb said
If you haven't bought this book yet, you really should. The first edition has been an invaluable asset to me on a number of past projects, and the second edition is even better with sections on newer language and framework features such as Linq and extension methods.
I've seen, read, and even written a few standards documents in my time as a professional programmer, and I think this book is the last one I'll be needing. The format of the book is one I always enjoyed, with the guidance interspersed with comments from the "peanut gallery" of Microsoft architects. These asides give you a lot of insight into the "why"s, something which a lot of standards documents are missing (I'm talking about YOU, IDesign). It's one thing to be told to do something in a particular way, but it's a lot better when you are taught why. Simple coding patterns that I wouldn't have given a second thought to have turned out to have a great impact on other aspect of my code once they were explained.
The basics are covered, such as naming and formatting standards, but the book goes much further with sections about when and how to use certain interfaces, and provides some brief explanations of common design patterns as they relate to the .net framework. I'm not talking about "Visitor" or "Model View Presenter" here, I'm talking about "IDisposable"... muuuch lower level stuff.
Basically, this book isn't just about what you ought to be doing, it's about explaining why Microsoft did what they did in the .net framework. It's refreshing at times in the book to find a discussion about how something was a bad choice in retrospect, or how the framework designers wished they had done something differently knowing then what they know now. I feel a lot better about my own changes of mind, and less like an amateur for not having seen the eventual solution in the beginning. After reading it, I'm more comfortable that I've made the right career decision to stick with this programming stuff.
Another great asset included with this book is the DVD. It's full of training sessions and example API specifications. One of the first things I did with the previous edition was to convert all the videos to play on my Zune, and spent the next few weeks watching through them whenever I got the chance. I probably won't watch them all over again, since I think they're the same videos, but they're definitely worth the watching.
Comments