I’m happy to announce that the first installment of my five-part screencast series on the S.O.L.I.D. object-oriented design principles, Refactoring to a S.O.L.I.D. Foundation, has just been posted to the DimeCasts.NET website for download or direct viewing.

In this series of short, 10 minute screencasts I will be applying each of the S.O.L.I.D. principles one by one to an existing sample software application to steadily improve its cohesion, flexibility, extensibility, and design.

The code sample for this installment can be downloaded here.

Why Bother?

In the wake of the recent dust-up between Joel Spolsky / Jeff Attwood and Uncle Bob Martin on the StackOverflow Podcast, a number of people (including, thankfully, Uncle Bob himself) have weighed in on both sides of the argument.  My own observation is that many people are staging their criticism from a position of misunderstanding of the intent of the principles and their practical applicability to software engineering.

For the record, I have been a long-time believer in the value of these principles; to me there aren’t so much new ground as a clever repackaging of simple basic OO engineering principles restated in a cute and memorable slogan (no offense intended to Uncle Bob; the observation, recognition, and cataloging of patterns is in itself a tremendous value to the profession ).

Like most patterns that one ‘discovers’, I have trouble understanding how anyone could question the value of such a basic set of observations with a straight face.  To me, its rather like when you first read the GOF Patterns book: you just go “Duh!  I’ve done that 100 times but I never knew there was a name for it!“.  It simply codifies practices that you have already found yourself doing in your own work over and over again.  That’s the meaning of the term ‘pattern’ in software engineering — they aren’t invented or discovered, instead they are observed repeatedly and eventually cataloged and documented.

Patterns vs. Principles

I tend to think somehow that if Uncle Bob had called them merely the S.O.L.I.D patterns instead of principles then this latest tempest-in-a-teapot probably never would have even occurred.  We as software engineers seem OK acknowledging that the application of patterns is heavily context-sensitive but apparently we somehow see a principle as something suggesting that it should be indiscriminately applied everywhere regardless of applicability to the problem at hand.

Check it out — one installment coming about every week!

So I figured that it might be time to demonstrate some concrete applicability of the these principles to a real-world engineering challenge (albeit a contrived one that somehow fits neatly into a 10-minute screencast ) so that people could start to see how these principles applied correctly can help to steadily improve the design of even a very simple OO software system.

Since it seemed to me that there was a great fit between the DimeCasts.NET format of 10-minutes-per-screencast and the number of these that would be needed to cover an intro to the S.O.L.I.D. principles (five — one for each of the letters of the acronym), I reached out to the founder of the site, Derik Whittaker, and inquired as to whether he was interested in taking some submitted content from me.  Happily, he was quite willing to accept the additional content and so over the next month or so he will be releasing my S.O.L.I.D. screencasts at a rate of about one a week as he has time to title them up with appropriate intro and outro content per the DimeCasts.NET standard.

Stay tuned for more announcements on these releases as they become available!

Even if you’re not interested in learning about S.O.L.I.D. OO design principles, long-time viewers of my other screencasts efforts like the Summer of NHibernate and the Autumn of Agile series might be interested to view one or two of them just to see that its indeed possible for me to provide content in a time-limit of under 3 hours