Framework Design Guidlines, with Brad Abrams and Krzysztof Cwalina
Today's sessions of choice was "The Art of Building a Reusable Class Library" - Brad has posted so much about this that I just had to attend. One great thing about this session is that they gave away copies of their book "Framework Design Guidelines" to most attendees. It's great to have a session that walks through the important stuff, along with well-constructed, more detailed material to take home.
Brad took the floor for the first half of the morning, primarily talking about naming standards and why they were used. A few highlilghts:
- The Power of Sameness is key - do things the way that the developer would expect (this would apply to end-users of applications as well), and they are much less frustrated than if you do things the "right" way but not in the expected way. Sameness with existing standards or commonly-used components is key to this
- Along this line, "optimize globally" - sometimes you have to make your code "less good" in order for overall global consistency and to make it easier to understand from a standards perspective
- Be careful about overloading - overloading is great for providing "defaults", but all overloads must actually do the same thing - if methods are semantically different, use different method names
- Defaults provided by overloads, or defaults on properties, should used the "zeroed case". This way developers can make an intelligent guess as to what the default is. This requires that parameter and property names be appropriate to the default.
- Constructor arguments should be shortcuts for setting properties - many users think in terms of "dragging a component on" and then setting properties, so allowing a parameterless constructor with the ability to set instance properties is helpful to these developers, even though less concise
Krzysztof then walked through material geared more towards framework design overall:
- Keep it simple - frameworks naturally become more complex and it takes explicit effort to make them simple
- Best way to start is to write sample code the way you want developers to be able to write code against your framework - number of "new" statements in sample code is indication of complexity, since each may require that the user needs to discover a class
- There are attributes that can be used to control debugger layout (DebuggertypeProxy - cool!) and provide hints to Intellisense - use them
- CLS (Common Language Specification) os a cpmtract between framework designers and language designers - your framework must be CLS compliant in order to work with all .Net languages
- Prefer abstract classes (or just base classes) to interfaces, in order to support extensibility
- Projects to develop libraries should have an explicit API designer role