In era of WPF, Silverlight, Sharepoint and Dynamics technologies, not to mention new Azure platform, seems so worthless to speak about how to perfectly design APIs and libraries in .NET framework. Maybe I’m wrong, but there is something missing when we constantly jump through the platforms in searching of better option. There is a quality penalty which appears if we just keep coding the novelties without taking into account the best practices, tips & tricks (although, there are none in case of new technologies), and basic design guidelines of building the software.
As I’ve already mentioned in some of my recent posts, Krysztof Cwalina and Brad Adams wrote a book about it called Framework Design Guidelines. And that is not all; there are myriads of technology experts who deal with this subject. Maybe you have great ideas in mind on how to design the code, and maybe I’ll enjoy reading it. Why not?
If you read new Application Architecture Guide (2.0), you will find the quality attributes as one obvious measure on how to know if the software is good. There are certain quality factors grouped in: System qualities, Run-time qualities, Design qualities, and User Qualities. Let me present them in a while:
System qualities are related to the overall system design (as supportability and testability), while others concern the capability of system to perform well in run-time (as availability, interoperability, manageability, performance, reliability, scalability, and security), to be good designed (as conceptual integrity, flexibility, maintainability, and reusability) and be user-friendly (as user experience indicator and usability).
Apart from that markups, framework should generally be designed as simple as possible. The classes should not contain any lines of code which are not necessary for the functioning, and the methods and other members should be totally refactored.
Although, we should not product spagetti code, the members should be utterly simplified. There are difficulties in doing this. For example, we should try to lower cyclomatic complexity and coupling of method calls and type dependencies. We should try to model components which are loosely-coupled.
We should consider also the ability of framework to add new functionality later. That means that we should not blindly design parts of our solution with the functionality “just in case”. This will be obsolete later, and eventually replaced by more proper code.
Also, there should be awareness of consumer of our code. There are specialities for different types of callers (spread maybe on different layers and/or tiers). Definitely consider WCF, Azure .NET Services or other similar technology when planning your deployment and integration with other parts of the system.
Visual Studio 2010 (but also its predecessor) can help you to present graphically the components you want to develop. Try to use system diagram, sequential diagram, class diagram, and other models to see if the components fits with each other. Plan for versioning of the code, because it’s inevitable part of the process. Maybe, VSTS 2010 (Rosario) could help you in these by visually presenting your branches of code.
Employ the static code analysis when you code. The compiler will constantly warn you about the errors you made, and about things you perhaps did not consider through the programming process.
As a conclusion, read the books I’ve mentioned. They will help you to better understand the philosophy and principles of best practice coding and how to perfectly design your frameworks or components (Framework Design Guidelines). They will also help you on how to decide which architecture style and metrics you should use and take into account (Application Architecture Guide).