HumansOfEpower: Understanding the SOLID Principles

SOLID Principles

Dear #HumansofEpower,

I’m Ayo, a 25-year-old developer who wants to understand how your agency writes codes that are clean, scalable and transferable.

Dear Ayo

Our workflow is guided by standard industrial practice and a huge dose of design. All our processes are design driven. We pride ourselves as being simple, not complex, divergent not usual & excellent not mediocre. Our developers use the understanding of solid principles to craft clean and scalable computer codes for all our projects.

Have you ever come across a code base (set of computer codes) and asked yourself: what is this Garbage? Writing a code that is secure and easily maintained should be the goal of every developer. We should never sacrifice readability for cleverness.

Let’s go a bit deeper so you can understand what SOLID principles mean:

SOLID is an acronym for the following five pillars that can help you write functional, secure and maintainable code:-

• S – Single Responsibility Principle (SRP)

• O – Open/Close Principle

• L – Liskov’s Substitution Principle

• I – Interface Segregation Principle

• D – Dependency Inversion Principle

Now that you know what SOLID principles mean, let’s take a look at each pillar in detail.

Single Responsibility Principle

The Single Responsibility Principle states that if we have 2 reasons to change for a class or function, we have to split the functionality in two classes / functions (A class is a part of a computer program that a programmer creates to represent a thing in a way that a computer can understand while a function is a named section of a program that performs a specific task.). Each class will handle only one responsibility and if in the future we need to make one change we are going to make it in the class/function which handles it. When we need to make a change in a class/function having more responsibilities the change might affect the other functions related to the other responsibility of the class.

Open / Close Principle

Open / Closed Principle stresses that Software units like classes, modules and functions should be open for extension but closed for modifications. The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.

Liskov’s Substitution Principle

Liskov’s Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a derived class without affecting the functionality of the program module.

We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise, the new classes can produce undesired effects when they are used in existing program modules.

Interface Segregation Principle

The Interface Segregation Principle states that classes should not be forced to implement interfaces they don’t use. Instead of one fat interface, many small interfaces are preferred based on groups of methods, each one serving one sub-module.

When designing an application, we take care of how we are going to make abstract a module which contains several sub-modules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface.

Dependency Inversion Principle

When designing software applications, we can consider the low-level classes the classes which implement basic operations and high-level classes the classes which include complex logic. The last ones rely on the low-level classes.

Let’s take the classical example of a copy module which reads characters from the keyboard and writes them to the printer device. The high-level class containing the logic is the Copy class. The low-level classes are KeyboardReader and PrinterWriter. In a bad design, the high-level class uses directly and depends heavily on the low-level classes. In such a case if we want to change the design to direct the output to a new FileWriter class we have to make changes in the Copy class.

If you’re like Ayo and would like to ask a question or make a submission, do drop them below in the comment section. Cheers.