Application Framework Principles

What is SOLID?

SOLID is a set of ideas derived from Robert C. Martin’s work in the early 2000s. It was offered as a means to consider the quality of object-oriented programming in particular. The SOLID principles, taken as a whole, argue for how code should be divided up, which sections should be internal or exposed, and how code should interact with other programs. I’ll go through each letter in detail below, explaining both its original meaning and an enlarged meaning that can be applied outside of object-oriented programming.

S.O.L.I.D stands for

• S: Single Responsibility Principle
• O: Open-Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

S-Single-Responsibility Principle

This principle states that a class should only have one duty, i.e., it should only solve one problem. Only changes to a specific section of the software’s specification will have the ability to change the class. This assures that there is only one reason for a class to change.

O-Open-Closed Principle

Classes should be available for extension but closed for modification, according to the open/closed principle. Simply, don’t change something that has been tried and proven to work for you. You can end up introducing new bugs into your program. Rather than changing the class, you can extend it to add new functionality.

L-Liskov Substitution Principle

The Liskov principle was named after Barbara Liskov, who first mentioned it in her 1987 keynote on “Data Abstraction.” According to the Liskov Substitution Principle, any child class of a parent class should be able to be used in place of its parent without causing any unexpected behavior.

I-Interface Segregation Principle

Many client-specific interfaces are better than one general-purpose interface, according to this principle. To put it another way, classes should not be required to implement interfaces that they do not need. The idea here is to separate the software into numerous highly-specific sections rather than having a general-purpose interface, which is an extension of the single-responsibility approach.

Dependency Inversion Principle

Classes should be based on abstractions rather than concretions, according to this principle. In practice, this means that higher-level classes with more complex logic and methods should be unaffected by lower-level classes, instead of relying on interfaces.