A brief, bird’s eye view of SOLID

SOLID is yet another acronym among a saturated sea of questionably important acronyms. This one itself however, is the shark. The predator, the one who continues to remain relevant in the world of object oriented programming. Here we will be going over the five pillars of SOLID and how they apply to object oriented programming in terms a novice coder can understand.

S- Single Responsibility Principle

The “Single Responsibility Principle” states a class (or module) should only have one responsibility and that responsibility is fully encompassed by said class. Once one gets to having multiple responsibilities, things start to get a little more dicey. A change to the class should solely affect the class we are working on.

O- Open/Closed Principle

This principle is simply defined as “an object should be open for extension but closed for modification.” If we want to specialize a class with some new qualities, we should not affect the initial object class, but an inherited class our object can reside in. This eliminates overlapping methods and date analysis.

L- Liskov Substitution Principle

This principle states we should be able to change an object in a subset without even slightly breaking our code. If natural peanut butter (subset) is a form of peanut butter (main PB class), we should be able to call on natural peanut butter without affecting the correctness or functionality of our code.

I- Interface Segregation Principle

As our computers communicate with each other using interfaces, we need to make sure these interfaces are as clearly delineated and confined to themselves as we can get them. This makes many things easier for many people overall. This should make refactoring and understanding your own code much easier, but at the same time it allows us to show a client small swatches of code of importance to them. We would not need to go through every individual aspect of the code in most cases, and this lets us go right to what we want.

D- Dependency Inversion Principle

Robert C. Martin wrote on this and many other processes of agile development in his book Agile Software Development, Principles, Patterns, and Practices. He defines this idea in two statements. Statement 1: High-level modules should not depend on low-level modules. Both should depend on abstractions. Statement 2: Abstractions should not depend on details. Details should depend on abstractions. To explain this we can use the example of politics. In a dictatorship with an all powerful ruler, the people are dependent on their ruler to help them. In the same regard, before this inversion principle there were King classes which were viewed as all powerful, with subsets beneath them who are just taking the instruction from the King. With the inversion applied, we suddenly have a democratic republic where the citizens can vote on topics and decide what happens amongst their government. In this scenario we see now the people still rely on the King, but the King relies on the people as well.

This has been a concise overview of the principles of SOLID. There are many resources out there if you seek more information.