In my previous post on design patterns I discussed about why it’s a challenge for developers / organizations to adopt patterns as part of their development practices. I also had suggested that a dedicated effort to re-factor code should be made continuously as part of software life cycle especially in the early to mid-stages of development. Having said that, how do you go about re-factoring? How do some of the object oriented principles and design patterns help with re-factoring? So, if re factoring is important, the object oriented mechanisms that allow and facilitate this are important as well. In conclusion the learning needs to happen, slowly and steadily – as a result it will start becoming a habit to incorporate some of these patterns related principles.

I guess the challenge is where do you begin? There is a ton of information on the web, it’s all too overwhelming, scattered and fragmented. You need a have a structure and if you just pick up the Gang of Four book (our bible for design patterns), it can seem rather academic and intimidating for the first timer, abstract as well. The book of course is great, however it’s hard to jump into patterns pragmatically just by reading it.

As in my previous post in my concluding paragraph I had said that getting familiar with SOLID principles developed by Robert. C. Martin is great way to get started with principles that will lead the way towards patterns programming later.  Before expanding upon technically on what SOLID is about, I would like to discuss its importance in the whole OO programming space. If you come from a OO language background like Java, C++, C# etc. you already are familiar with Encapsulation, Inheritance, Polymorphism as foundational principles of OO and they are a daily part of your programming life. SOLID takes it one step further, lays out 5 principles that you can apply to re-factor and improve the code making it maintainable, reusable and efficient.

So when you start applying SOLID, you basically are applying some of the fundamental principles on which Design Patterns are developed. SOLID stands for Single Responsibility, Open-Closed principle, Lishkov Substitution principle, Interface Segregation and Dependency Inversion.

If you just take the first two: Single Responsibility and Open-Closed principle, just there you will improve the structure and quality of your classes.

Single Responsibility states: a class should have only a single responsibility.

Say, you are writing a Log class whose job is simply to write messages to different logging mediums. However you also gave it the responsibility of formatting the messages for these mediums, because it’s part of logging function. In addition, you gave it the responsibility of initializing and choosing the medium to log into, for ex: Event logs, Database, Log files etc. So now the Logger class has multiple reasons to change – one is, Write to the log medium, another is formatting the message: perhaps different mediums require different formatting and on top of that initializing the medium . So your class has now grown into one giant monolithic program that has multiple reasons to change – formatting for each medium, initializing the medium and logging to the medium. So if you need to change only one aspect : say change the formatting messages in database , you have to change that class and the rest of the code could possibly break because you needed to make changes for one aspect. We come across situations like this all the time in production code where we change one thing and potentially something else breaks , without us intending it . This sort of programming makes the code not only fragile, but totally un-pluggable.

Ideally in this situation, the Logger class should just take on the responsibility of writing to the medium being free of what medium it is writing to and what formatting that particular medium needs. Although it seems like they are all related functions , they merit to become individual classes based on their specific function and behavior. More so, ideally you should write an interface that can be implemented to write to different log mediums.

public interface ILog
{
void Write(String Message);
}

As you see , when you just take this one principle and follow it while writing the code you will see that you have written classes that are light weight and each is meant to do one particular job – this makes the design pluggable , reusable and efficient  . You can create classes that are specific to a medium – so adding mediums for logging becomes easy later. Also if there is a change required in it , say how you format the message for that medium, you change only the corresponding medium or the formatting class, avoiding the risk of the rest of the code breaking due to the one change you made in one big class.

As you go further and start applying one by one each principle you will see that certain patterns are shaping up, and possibly they can be applied to common scenarios. I guess I will stop here for now, and conclude that the first step is definitely to understand SOLID and start applying it in your programming life seriously.

Below is a great Video on Single Responsibility Principle by Robert C. Martin himself to learn more on it and get started :

We will discuss more on the rest of the SOLID in the upcoming post …until then happy programming.