The SOLID principle is the 5 rules that object-oriented programming (OOP) follows. These rules or principles can be used to create software that is easy to extend and maintain, while avoiding code smells and allowing simple refactoring. Obviously, these five principles are not a panacea, they will not repair any code base or make your code base magic. Even if you follow these rules, you can write code that makes maintenance and refactoring difficult. These rules should be good things to keep in mind when designing and writing software, but they can also be used in conjunction with coding guidelines and other concepts (such as design patterns).
I will introduce all 5 principles in this article, but will also link to other articles in which I will explain each principle in more depth through code examples and code snippets. If you do n’t understand OOP or want to review it, I suggest you read these posts before explaining the basics of OOP.
Interfaces and abstract classes
Single responsibility principle
The Single Responsibility Principle (SRP) is probably the easiest of the five principles to understand. There should be only one job per class. It seems very simple, even if developers strive to follow it, most developers can tell you. What is difficult to understand with this principle is that the single responsibility of a class can be very specific or abstract. For example, you may have a class whose purpose is to save rectangular data, its size and position, but for a class, you can have a more general class that saves all the data of the rectangle and handles calculations Area and perimeter. The second example can perform multiple tasks, can calculate its area or perimeter, but still has only one responsibility-processing rectangles. If the user signature is also processed in the same category, it will no longer be responsible and will therefore destroy the SRP.
The important thing to remember about the single responsibility principle is that each class should have a clearly defined purpose for the existing existence and can only do one thing. This matter may be very specific, such as processing a rectangle, or more general, and has multiple operations (such as processing user authentication). The principle can also be extended to a smaller scope, each class should have a single purpose, and each method in that class should have a more specific single purpose.
Read more about the single responsibility principle here .
Principle of opening and closing
The open-closed principle states that objects should be open for expansion and closed for modification. This means that any object should also be easy to extend or add functionality, but it should not be modified or changed. It is difficult to understand this principle at the beginning, because it is meaningless outside the OOP paradigm. Suppose we have a piece of code that deals with a specific function and then compiles the code so that we cannot change it. We should be able to add functionality to the code so that it can be expanded and extended without modifying the source code, but can be closed for modification. Obviously, this is not possible outside of OOP, because to add functionality, we must first change the source code and then recompile the code. However, in OOP, you can use the compilation source of the class and inherit from it in the new class-the new class will be a child of the pre-compiled class. Inheriting from the base class allows you to add features that the base class does not have, and also allows the base class to remain modified. In short, when inheriting from a base class, you do not have to change or modify the base class.
Read more about the open and closed principle here .
Riskov's principle of substitution
The Liskov replacement principle states that any subclass can be replaced wherever the base class is used. This means that if there is a place in your code that uses a base class, or any class that has subclasses, then it should be possible to use any of its subclasses without breaking the code or changing the code. If you replace the base class with the implementation of any of its subclasses, you should not make any difference and do not create errors or errors. This principle ensures that the inheritance tree actually follows the correct inheritance relationship and forces you to consider the inheritance hierarchy, not just extend from the base class to the copy function.
Read more about Liskov's substitution principle here .
Interface isolation principle
The interface isolation principle states that classes should not be forced to implement interfaces or methods that they do not use, or interfaces or methods that are not feasible in this case. When coding in the context of OOP, polymorphism is usually used, so common code can be used in many different concrete implementations. However, this may cause the class to implement an interface to allow polymorphism, which is actually meaningless. For example, the class that handles contact information should not be implemented from the class or interface that handles the salary or hourly wage of the person. Another reason people violate the interface isolation principle is because their interfaces contain too many methods. Suppose you have an interface that can force the implementation of two methods "talk" and "fly", these two methods will be used for different types of birds. However, some birds cannot fly, so if you create a class for the Dodo bird, you will implement it from this interface and then be forced to implement the "fly" method that makes no sense in this case. This does not mean that each interface should have only one method. Breaking down your interface into components of reasonable size is a difficult thing, and will most likely lead to refactoring your codebase later. The physical component system design pattern is a good example of the interface isolation principle.
Read more about the principle of interface isolation here .
Dependency principle
The dependency inversion principle states that any entity should rely on abstract rather than concrete implementation. This means that you should use polymorphism to make your class depend on interfaces or abstract classes, rather than the concrete implementation of dependencies. This allows you to easily swap out specific implementations without having to refactor your base class. This is a useful rule to follow, but it will quickly get out of control because you can create an interface for each concrete class in the code base.
Read more about the dependency inversion principle here .
The SOLID principle is an important rule to follow, which can make your code base easy to maintain, expand and avoid odors. However, adopting any of these principles and running with them will actually make your code base worse. For example, keeping your code completely unmodified will prevent any refactoring or functional changes, making every concrete class dependent on an interface, which will lead to a huge code base that needs to be managed, and so on. The important thing is to check the code base, if you can't fully follow the principles that can be. Like many software-related tips and tricks, treat them as good guidelines rather than strict systems that must be followed exactly.
The post was originally posted on https://acroynon.com
from: https://dev.to//acroynon/the-solid-principles-15a5
