I finally got around to watching best practices for designing frameworks that are reusable object-oriented libraries. The presentation is based on the content from MSDN’s Design Guidelines for Class Library Developers and the Framework Design Guidelines book.
- 100% .Net focused – some topics that you’d only consider in a .Net environment
- Well organized
- Well presented for a developer presentation, I liked the analogies and a great quote from Napoleon
- He gives an overview of Microsoft’s api review process, including mentioning a tool that makes an API word document from the code. I haven’t searched for the tool yet.
- There’s a 20 minute section at the very end where he explains constructing teams that produce good API designs
- It’s long; there is a “fast mode” that makes the presentation watch-able in 1 sitting though
- The speaker is a bit repetitive at times to really “hammer home” a point
- No details on processes or tools that help an organization measure “API effectiveness” or “API cost”
- No helpful ways to train and educate “shu” level on good API design other than reading the design guidelines. He recommends having someone who is “ha” or “ri” level be responsible for the API on a project and have an organization wide API review team for inter-project API consistency.
Overall, I would recommend watching this if you haven’t already read the MSDN site or the book and want to be a good .Net API designer and have your code “feel like” the .Net framework code.
Joshua Bloch’s “How to Design a Good API and Why it Matters” has more value for the time spent watching the video, and is more concentrated on non language specific OO design guidelines making Bloch’s video more universally true and probably more timeless. The .Net video has its place however; I’m glad that I finally watched it but I don’t think I’ll have a need to watch it again any time soon. Having discussed many of the .Net API Design Guidelines and consumed many .Net libraries a lot of the concepts are ingrained into my practices and expectations already.I am thankful, however, that API design resources like this are published in a medium from which I may learn.