May 14, 2009

...Learn TDD with Codemanship

Design Principles Finally Coming Into Fashion In The .NET Community (Hurrah!)

One of the more encouraging trends this year that I've noticed is a maturing in the way many in the .NET/Microsoft developer community reason about software design.

It seems we've been through various phases, starting with fairly mindless copying of example architectures (Duwamish Books, for example) in the false belief that following a specific naming convention ("UI.xxx, BusinessLogic.xxx, DataLogic.xxx etc) will achieve high cohesion and low coupling in our application code (don't get me started on the fallacy of "layered" architectures - I too was a happless victim once).

Then, perhaps in a misguided attempt to ape the Java community, we had a massive push on patterns. GoF patterns (and let's be honest now, most developers only really learned the Factory pattern), MVC (more on that in a minute) and Patterns of Enterprise Application Architecture.

MVC in particular is still de rigeur and developers and architects alike still delude themselves that, just because they're using a framework with MVC in the name, that they're achieving a genuine seperation of concerns. Likewise with layered architectures and with patterns; run a proper dependency analysis and you tend to find that major problems with coupling still somehow creep into the code.

And that's because the only way to effectively manage the dependencies in your code is to manage the actual dependencies in your code effectively. Managing dependencies in your code is not a simple matter of putting socks in the sock draw and t-shirts in the t-shirt draw. You have to consider every relationship in its own right. If I always wear the Dalek socks with the TARDIS t-shirt, then they belong together in a Dr Who draw. In years of coaching developers and architects in good design, the Microsoft developer community has been most insistent in their requests that I should give them "the formula" that will resolve all dependency issues. Now I get a real glimmer of hope that a small kernel of the best and most influential .NET developers are actively exploring the idea of tackloing design problems on a case-by-case basis, applying dependency management principles instead of canned answers.

Enter stage right Robert Martin's SOLID design principles. SOLID stands for:

* Single Responsibility (classes should only have one reason to change)
* Open-Closed (classes should be open to extension and closed to modification)
* Liskov Substitution (an instance of any class must be substitutible by an instance of any of its subtypes)
* Interface Segregation (classes should present small, client/role-specific interfaces so that changes to methods used by one client don't impact on clients who use differnt methods)
* Dependency Inversion (NOT the same thing as "dependency injection", BTW! - essentially, depend on abstractions rather than their concrete implementations, and don't have higher level modules depend on lower-level modules)

Martin Fowler states that it's preferable to master general principles than to memorise catalogues of applications of these principles. Design patterns are applications of design principles, and most of us will have moved towards these insights via years of studying and applying patterns.

At the risk of patronising our .NET compatriots, the exciting new fashion for learning design principles - old news as they may be to patterns veterans of the 90's - means that .NET software design is growing up and hopefully becoming more sophisticated. I look forward to seeing that reflected in future code bases with fewer dependency issues. That may take another year or three, but it's an exciting prospect nevertheless, and one which I roundly applaud.

The next step may be in realising that the design principles we've known about for decades now are actually an unfinished work-in-progress. The distractions of UML, CBD, Agile, SOA et al have caused research and developments in real design (design of actual code as it actually gets written by actual programmers, that is) to stall for about a decade. Plans are afoot to jumpstart this work again, which is also potentially very exciting.







Posted 9 years, 1 month ago on May 14, 2009