SOLID principles in Software Engineering.

What are SOLID principles and why do we need them?

"The purpose of software engineering is to control complexity not to create it" - Pamela Zave

When it comes to software engineering, it is always more than about the code or the programming language that you use or even the framework of choice.

A famous quote by Ruth Malan is "If architects built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization"

This quote tells about how much bad code is written and its large impact over time. SOLID principles when followed will help you not only be able to design good software but also that with manageable dependencies. Of course, when it comes to software designing the problem to be solved is always a large

parameter.

SOLID is an acronym for the following

S - Single responsibility principle (SRP)

O - Open and close principle (OCP)

L - Liskov Substitution principle (LSP)

I - Interface Segregation principle (ISP)

D - Dependency inversion principle (DIP)

Single Responsibility Principle (SRP)

The Single Responsibility Principle tells us that a module should have exactly one reason and one reason to change.

Consider this example

This is an Employee class that has three methods, calculatePay, reportHours, save. This employee class is depended by three actors let us say the CFO team,

COO team and the CTO team, let's say that the CFO team what to change the formula of calculating the Pay, this means that this method will not only affect the CFO team but also COO team and the CTO team hence bringing inconsistencies in their work and may result to them losing large sums of money due to this problem.

So the question is what brought the problem and how can it be fixed? The problem was brought by a bad design flow that completely violated the Single Responsibility Principle. The flaw above can be fixed by breaking the employee class to three more classes such that one class has one responsibility to take care of and the same for the others. This is just one of the solutions though you can think of a million other solutions just not to violate this vital principle.

Open and Close Principle (OCP)

The open and closed principle states that a module should be open for extension but closed for modification.

This means in terms of your code, your old code should not rely on your new code but the new code should rely on your old code. When we talk of modification sure enough it means that you are not supposed to change the old code but it also means that old code should not recompile because of your new code. Your new code should only act as an extension and not a modification of the old code.

It may be hard to achieve this since sometimes modification is needed but it should be as minimal as possible.

Liskov Substitution Principle (LSP)

LSP deals with the relationship between a base class and its derived classes in an inheritance hierarchy. The derived classes should be substitutable for their base class without affecting the correctness of the program.

It goes on and emphasizes that the derived class must adhere to the contract established by the base class. This means that the behavior specified by the base class should be preserved and not altered by the derived class.

This is why we say that in OOP a square is not a rectangle as it would violate this principle.

Interface Segregation Principle (ISP)

ISP states that a class should not be forced to implement interfaces it does not use.

It focuses on the creation of fine-grained, client-specific interfaces, avoiding the imposition of unnecessary methods on implementing classes which leads to more cohesive and maintainable code.

Dependency Inversion Principle (DIP)

DIP state that High-level modules should ot depend on low-level modules. Both should depend on abstractions.

DIP advocates for designing systems where high-level modules define the overall policies and low-level modules handle the specific implementation details. This is in contrast to a traditional apprach where high level modules directly depend on low-level modules.

DIP emphasizes the importance of designing systems where high-level and low-level modules depend on abstractions, promoting decoupling, flexibility, and ease of maintenance. This principle is fundamental in achieving a more modular adaptable architectrue in object-oriented software development.

In a nutshell, this design principles helps in helping you know how to lay down the blocks that are fundamental for designinig your software.