Quite often I meet developers who have not heard about the principles of SOLID (we . - Transl.) or object-oriented programming (OOP), or heard, but do not use them in practice. This article describes the benefits of OOP principles that help the developer in his daily work. Some of them are well known, others not so much, so the article will be useful for both beginners and already experienced programmers.
We remind you: for all readers of "Habr" - a discount of 10 rubles when enrolling in any Skillbox course using the "Habr" promotional code.
Skillbox recommends: Educational online course .
DRY (Don't Repeat Yourself)
A fairly simple principle, the essence of which is clear from the name: "Do not repeat yourself." For a programmer, this means the need to avoid duplicate code, as well as the ability to use abstraction in work.
If there are two repeating sections in the code, they should be combined into one method. If a hardcoded value is used more than once, it is worth converting it to a public constant.
This is necessary in order to simplify the code and make it easier to maintain, which is the main task of OOP. You should not abuse the union either, since the same code will not pass the check with both OrderId and SSN.
Change Encapsulation
The software products of most companies are constantly evolving. This means that the code needs to be changed, it needs to be maintained. You can make your life easier with encapsulation. This will allow you to more effectively test and maintain your existing code base. .
If you are writing in Java then .
The principle of openness / closeness
This principle can be easily remembered by reading the following statement: "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." In practice, this means that they can allow their behavior to be changed without changing the source code.
The principle is important when changes to the source code require revisions, unit testing, and other procedures. Code that obeys the open/closed principle does not change when extended, so there are much fewer problems with it.
Here is an example of code that violates this principle.
If you need to change something in it, it will take a lot of time, because you will have to change all the parts of the code that have a connection with the desired fragment.
By the way, openness-closedness is one of the principles of SOLID.
Single Responsibility Principle (SRP)
Another principle from the SOLID set. It says that "there is only one reason that leads to a class change." The class has only one task. It may have several methods, but each of them is used only to solve a common problem. All methods and properties should serve only this.
The value of this principle is that it loosens the link between a single piece of software and the code. Adding more than one functionality to a class introduces a relationship between the two functions. Thus, if you change one of them, there is a great chance to spoil the second, related to the first. And this means increasing the testing cycles in order to identify all problems in advance.
Dependency Inversion Principle (DIP)
The above is a code example where the AppManager depends on the EventLogWriter, which in turn is closely related to the AppManager. If you need a different way to show the notification, be it a push, SMS, or email, you need to change the AppManager class.
The problem can be solved with DIP. So, instead of AppManager, we request an EventLogWriter, which will be injected using the framework.
DIP makes it possible to easily replace individual modules with others by changing the dependency module. This makes it possible to change one module without affecting the others.
Composition instead of inheritance
The two main ways to reuse code are inheritance and composition, each with its own advantages and disadvantages. The second one is usually preferred because it is more flexible.
Composition gives you the ability to change the behavior of a class at run time by setting its properties. When implementing interfaces, polymorphism is used, which gives a more flexible implementation.
Even "Effective Java" Joshua Bloch advises favoring composition over inheritance.
Barbara Liskov Substitution Principle (LSP)
Another principle from the SOLID toolkit. It states that subtypes must be replaceable for a supertype. That is, methods and functions that work with a superclass should be able to work without problems with its subclasses.
LSP is related to both the Single Responsibility Principle and the Separation of Responsibility Principle. If a class provides more functionality than a subclass, then the latter will not support some functionality, violating this principle.
Here is a piece of code that contradicts LSP.
The area(Rectangle r) method calculates the area of ββa Rectangle. The program will crash after executing Square, since Square is not a Rectangle here. According to the LSP principle, functions that use references to base classes should be able to use objects of derived classes without additional instructions.
This principle, which is a specific definition of a subtype, was proposed by Barbara Liskov in a 1987 conference keynote called "Data Abstraction and Hierarchy" - hence its name.
Interface Separation Principle (ISP)
Another SOLID principle. According to him, an interface that is not used should not be implemented. Following this principle helps the system remain flexible and refactorable when making changes to the logic of work.
Most often, this situation occurs when the interface contains several functionalities at once, and the client needs only one of them.
Since writing an interface is a complex task, after the work is completed, changing it without breaking anything will be a problem.
The advantage of the ISP principle in Java is that all methods must be implemented first, and only then they can be used by classes. Therefore, the principle makes it possible to reduce the number of methods.
Programming for an Interface, Not an Implementation
Here everything is clear from the name. Applying this principle leads to flexible code that can work with any new interface implementation.
You should use an interface type for variables, return types, or the type of a method argument. An example is using SuperClass rather than SubClass.
That is:
List numbers= getNumbers();
But not:
ArrayList numbers = getNumbers();
Here is a practical implementation of what is said above.
Delegation principle
A common example is the equals() and hashCode() methods in Java. When two objects need to be compared, this action is delegated to the appropriate class instead of the client class.
The advantage of the principle is that there is no duplication of code and it is relatively easy to change behavior. It also applies to event delegation.
All these principles allow you to write more flexible, beautiful and reliable code with high cohesion and low coupling. Of course, theory is good, but for a developer to really start using the knowledge gained, practice is needed. The next step after mastering the principles of OOP can be the study of design patterns for solving common software development problems.
Skillbox recommends:
- Practical course .
- Applied online course .
- Two-year practical course .
Source: habr.com