SOLID Principles: A set of guidelines for writing clean and maintainable code.

Like every other principles that are applicable to different spheres of life, object-oriented programming has certain fundamental design principles that makes object-oriented programming flexible, scalable and understandable.
Today, we will be rubbing minds on one of the most fundamental of these principles— The SOLID principles.

As it is known, a good system/application requires a good code base that is easy to maintain, thus, the need for sets of widely accepted guidelines for writing clean and mainatainable codes. This, which necessarily aids collaborative work ethics in the tech industry.

SOLID, being an acronym generated from the initial alphabets of five(5) basic principles:

S- Single-responsibility Principle(being the first)

O-Open-closed Principle

L-Liskov Substitution Principle

I- Interface Segregation Principle

D- Dependency Inversion Principle

Let’s cast our minds off any ambiguity from these words above as these threads will attempt to simplify these principles with practical structures and examples starting with the first principle— Single-responsibility principle.

1. Single-responsibility Principle, as the name implies, the principle enjoins the art of making a pattern to be solely responsible for a particular activity in a system. As popularly stated: “A class should have one and only reason to change, meaning that a class should have only one job in a system”. The above-stated doesn’t necessarily imply that a class should have one method, function or property. Rather, it means that functions in a class should behave to reflect a single responsibility, thus, having close reasons and relationships to effect a general goal.

In a real life scenario, making class reps for different courses in a particular class reliefs a person from carrying different burdens. Unlike the traditional way, a person is made to carry different responsibilities for a particular group of persons, but once a person is attached as a class representative for a particular subject, responsibilities weigh less and this aids single responsibility. In essence, loose-coupling happens, thus making our system easy to maintain.

2. Open-closed Principle. This implies that codes must be open for extensions and closed for modifications. The simple logic is change and as we all know, change is permanent as our codes require change over time to stand the test of time. However, a good code must be able to maintain the existing structure, and open for additional features without tampering with any fundamental base. A real time instance that suits the principle is in instances where a car owner upgrades the car features without tampering with the vehicle chassis. The owner may choose to replace the manual gear system with an automatic, even there can be an upgrade of the sound system from one with cassette player to a CD effect player. Nowadays, cars without full option features from production can be upgraded to have full options features like reverse camera, etc.
All these are inline with the open-close principle because the vehicle class is made to depend on the abstraction of the gear system or sound system or any other component system just so it can use any type of the concrete system.

This, effectively aids the single-responsibility principle which necessarily means that the more responsiblities that your class has, the more need to make changes, thus, the proneness to many complications and effects. In a simple-built structure, it is easy to add new extensions without altering the existing ones.

We’ll be stopping here today for easy dissect and proper breakdown. Stay tuned for the concluding explanation on SOLID principles.