The SOLID principles are 5 rules of object-oriented class design. They were created by Robert C. Martin, also known as Uncle Bob, in 2000. The SOLID principles can apply to various programming languages. They help developers understand the need for certain design patterns and software architecture. In this article, we will explain in detail what SOLID is.

SOLID – what is it?

The SOLID principles are 5 rules of object-oriented class design. They were created by Robert C. Martin, also known as Uncle Bob, in 2000. The SOLID principles can apply to various programming languages. They help developers understand the need for certain design patterns and software architecture. In this article, we will explain in detail what SOLID is.

5 SOLID principles 

Adopting the SOLID principles is the way to avoid code smells, refactor code and develop software more easily. The result, if properly applied SOLID rules, is an understandable, testable, and readable code that many developers can collaboratively work on. The following 5 concepts make up the SOLID principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Let’s take a closer look at them!

Single Responsibility 

The author of the SOLID rules explains that ‘a class should have one, and only one, reason to change’. So, simply speaking, each class in the code should solve only one problem – only one potential change in the software specification should be able to affect the specification of the class. This principle can be applied to classes, as well as software components and microservices. Using the Single Responsibility principle properly makes the code easy to maintain and test.

Open/Closed

This principle requires that classes should be open for extension and closed to modification. When we say extension, we mean adding new functionality. When we say modification, it means changing the code of an existing class. Here is how Martin explained the principle: ‘You should be able to extend a class’s behavior without modifying it’. Following this rule makes the code easier to maintain and test.

Liskov Substitution Principle 

The rule states that subclasses should be substitutable for their base classes. Every subclass or derived class should be substitutable for their base or parent class. Given that class Z is a subclass of X, we should be able to pass an object to class Z to any method that expects an object of class X and the method shouldn’t give any weird output in that case. If the class doesn’t obey this rule, it may lead to bugs that are difficult to track.

Interface Segregation

According to the Interface Segregation rule, it is much better to have a lot of smaller interfaces than a few bigger ones. In other words, clients should not be forced to implement a function they do not need. Engineers should work to have many client-specific interfaces, instead of having one general-purpose interface.

Dependency Inversion 

According to the Dependency Inversion, classes should depend upon interfaces or abstract classes instead of concrete classes and functions. Classes should be open to the extension so that dependencies are reorganized and depend on interfaces.

See learn more on SOLID principles see this in depth explanation of SOLID in PHP as well ass check out this code repository with a lot of examples. 

LEAVE A REPLY

Please enter your comment!
Please enter your name here