S.O.L.I.D. Principles (No more tears)

All far-fetched, bad puns aside, it's time to explore the OOP-newbie-lifesaving-principles that are S.O.L.I.D. -- what they stand for and what purpose they serve. 

Introduced to the world as S.O.L.I.D. by Michael Feathers, the acronym refers to the first five object-oriented design (OOD) principles by Robert "Uncle Bob" Martin. So, what exactly are these infamous OOD principles? 

• S - Single-responsibility principle
• O - Open/closed principle
• L - Liskov substitution principle
• I - Interface segregation principle
• D - Dependency inversion principle

Now that we know what S.O.L.I.D. stands for, let's try and understand these five principles, one at a time.

Single-responsibility Principle (SRP)

Robert C. Martin expressed this principle as, “A class should have one and only one reason to change, meaning that a class should have only one job”. This means that a class should exist for one purpose and one purpose only. Just because we can add everything we want to our classes, does not mean that we should. Here, thinking in terms of responsibilities will help us design our applications better. Should the logic that we are introducing to a class live in itself or not? If the answer is "not", splitting big classes (or as everyone likes to call them, God classes) into smaller classes, hence assigning one responsibility per class will surely help.

Open/closed Principle (OCP)

Open/closed principle states that "software entities should be open for extension, but closed for modification." And how exactly do we do this? By changing the behavior of a class using inheritance and composition. When we create base classes with functions that can be overridden, we are able to create new classes which do the same thing without modifying the base functionality.

Liskov Substitution Principle (LSP)

Every subclass/derived class should be able to substitute to their parent/base class. In other words, we should be able to substitute an instance of a subclass to its parent class and everything should continue to work. Therefore, the child class should not have unimplemented methods as well as it should not give a different meaning to the methods which exist in the base class after overriding them.

Interface Segregation Principle (ISP)

"Clients should not be forced to depend upon interfaces that they do not use." This was Robert Martin's idea of ISP. It urges to keep our application interfaces simple and cohesive, by splitting very large interfaces into smaller and more specific ones, so that the clients will only have to be aware of the methods that are of interest/relevance to them.

Dependency Inversion Principle (DIP)

DIP states that "high-level modules should not depend on low-level modules, but both should depend on abstractions" whereas, "abstractions should not depend on details, but details should depend on abstractions". Basically this means that we should isolate our class behind a boundary of abstractions it depends upon, so that even if the details of the abstractions change, the class would still remain safe.

By now we understand that most of these principles promote loose coupling between classes that would otherwise be highly dependent on each other. This involves adding a layer of abstraction between the said classes that would prevent such dependencies, hence resulting in a code that is easier to extend as well as maintain.