S.O.L.I.D. Object Oriented Design Principles (Intro)

The Object Oriented Paradigm has been broadly used in the Industry for the last couple of decades. There are many popular programming languages that embrace this paradigm such as Smalltalk, Java, C++, C# among others. Even though OOP is defined by few fundamental concepts such as Inheritance, Encapsulation and Polymorphism; mastering a proper OOD skill set may take several years.

When I was introduced to the famous OOP Design Patterns GoF, I wanted to use them at any opportunity possible in my projects till the grade to anti-pattern. Getting deeper into application architecture, I came across to some withe papers by Robert Martin talking about "Object Oriented Design Principles," at the first glance I thought they were extensions to the GoF patterns but then I realized that they were describing the core of the Object Oriented Design essence.

In the past, I have done a couple of presentations and brown bags at work covering the S.O.L.I.D. principles with different type of attendees (with technical and/or business backgrounds). I have developed some material for exposition and I wanted to publish it into this post, hopefully you may find it interesting.

The OOD Principles are:

Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion (a.k.a. Inversion of Control)

Why these Principles are important?
This is a common question that I have heard quite often.These principles are key to solve problems in our application designs, many of us have created or come across with designs that are too structured or difficult to understand.

Symptoms of Rotting Design:

Rigidity: Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules.

Fragility: Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed.

Immobility: Immobility is the inability to reuse software from other projects or from parts of the same project. 

Viscosity: Viscosity comes in two forms; viscosity of the design, and viscosity of the environment. When faced with a change, programmers usually find more than one way to make the change.

This post is the introduction of a series where I will cover each one of the principles.