SOLID Principles - Five Principles of Object-Oriented Programming and Design

This is the first of what will be a series of posts on each of The SOLID Principles.

Before we go into details lets look at an overview of the principles.

Every software developer should be aware of the acronym “SOLID” and what it stands for. If you have not then you really should read this blog to learn it. Even if you do, there’s a good chance your understanding might be a bit fuzzy and a refresher on it never hurt anyone. Young developers especially need to be aware of the Solid Principles and be able to name the 5 principles and explain what each one does. I guarantee that you will be asked about them at some point during a technical interview for a job.

In the early 2000s Robert C. Martin, commonly known as “Uncle Bob”, came up with a list of 11 principles of good Object Oriented Design (OOD). The first five principles are principles of what makes good class design. These five principles are what have become known by the acronym “SOLID” which Michael Feathers helped coin. These principles when learned and implemented correctly help developers create and maintain a codebase that is strong but flexible to grow and change with minimal difficulty.

The five principles are as follows:

• S – Single Responsibility Principle (SRP)
• O – Open Closed Principle (OCP)
• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)

When you look at a quick description for each of this principles, you might find yourself saying, “Well that’s obvious” but keep in mind that for many young developers these ideas aren’t always so clear as to why they are important.

The Single Responsibility Principle (SRP) states that “A class should have one, and only one, reason to change.” Think of this as a warning not to create monolithic god objects that try to do too many different things.

The Open Closed Principle (OCP) states that “You should be able to extend a classes behavior, without modifying.” This is all about using polymorphism and abstraction to build new functionality.

The Liskov Substitution Principle (LSP) states that “Derived classes must be substitutable for their base classes.” The idea behind this principle is that code should be written such that if you create a new derived class from a base class you should not have to modify code to work with this derived class.

The Interface Segregation Principle (ISP) states “Clients should not be forced to depend upon interfaces that they do not use.” This is all about building multiple interfaces that will provide only the methods that a client needs. Simple put it’s better to have two smaller interfaces than one large fat interface.

The Dependency Inversion Principle (DIP) states “Depend on abstraction, not on concretions.” Dependency Inversion, often confused with Dependency Injection, is all about building classes that are created to use abstractions of 3rd party objects so that the concrete objects can be changed at will without needing to rewrite your code.

There are some that disagree with the idea of SOLID and claim that it’s the wrong idea and even dangerous to follow. Other’s might say they are outdated. I would say to those people that they need to remember that these are just principles that when it makes sense to follow can help you write good code. SOLID is not a panacea and you should not dogmatically follow it.

I can understand where they may be coming from. Blindly following principles is something that young and inexperienced developers may often do, they learn of a new methodology or tool that seems like a good idea and they attach to it and try to use it for everything, even when it doesn’t make sense.

That being said, I believe the SOLID principles are very useful and a great guide to help you make sure all the code you write is of the best quality you can.

Stay tuned for future posts that will breakdown each of the SOLID Principles!