S.O.L.I.D. – Principles of Object Oriented Design


Principles of Object Oriented Design

SOLID is a mnemonic acronym for five principles of Object Oriented Design (OOD) by Uncle Bob (Robert Martin).

These principles, when followed make it easy for a programmer to develop software that is easy to maintain and extend. They provide a clear guidance for moving from tightly coupled code with poor cohesion and little encapsulation to the mature results of loosely couple code which operates very cohesively and encapsulates the real needs of business. Whether you are beginner or experienced champ these principles when used correctly leads to design of effective, maintainable, object-oriented systems.

In this article we will just cover the basic definition and what each principle tells us.

What is S.O.L.I.D

Let’s look at each principle individually to understand why S.O.L.I.D can help make us better developers:


1)     Single-responsibility Principle

S.R.P for short this principle says that there should never be more than one reason for a class to change. This helps to drive cohesion into a system and can used as a measure of coupling as well. So in short a class should exist for one purpose only.

2)     Open Closed Principle

OCP for short, this principle says that how a system should be extended by modifying the behaviour of software entities (classes, modules, functions etc), without modifying the entities itself. In short the entities are open for extension but closed for modification. This helps the developers to create highly cohesive systems. Abstraction is a way we can achieve this- All the methods which are expected to have change in behaviour should be declared as abstract. The derived classes can override the method and provide their own implementation (behaviour).

3)     Liskov’s Substitution Principle

LSP for short, this principle says that derived classes must be substitutable for their base classes. Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. It basically wants us to think clearly about the expected behaviour and expectations of a class before you derive new classes from it.   A subclass should override the parent class methods in a way that does not break functionality from a client’s point of view. The LSP applies to inheritance hierarchies.

4)     Interface Segregation Principle

ISP for short, this principle says many specific interfaces are better than a single, generic interface. In simple words, we should not let our end user depend on an interface which he doesn’t need; rather we should make fine grained interfaces that are end user specific. This helps you to develop well encapsulated, cohesive system which is easy to understand and use.

5)     Dependency Inversion Principle

DSP for short, this principle says how we should bind our system together correctly. Following this principle helps a developer to create a system that is couple correctly and directly influences its encapsulation and cohesion. It tells that high level modules should not be dependent on low level modules rather both should be dependent on abstraction. Abstractions should not depend on details.  Details should depend upon abstractions. The effect of the DIP is that classes are loosely coupled. This increases the robustness of the software and improves flexibility. The separation of high level classes from their dependencies raises the possibility of reuse of these larger areas of functionality. Without the DIP, only the lowest level classes may be easily reusable.