{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principles of object-oriented programming that every developer should know","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nI often encounter developers who haven't heard of the SOLID principles (we discussed them in detail here<\/a><\/noindex>. \u2014 Ed.) or object-oriented programming (OOP), or have heard of them but do not use them in practice. This article describes the advantages of OOP principles that assist developers in their daily work. Some are well-known, while others are not so much, so the article will be useful for both beginners and experienced programmers.
\n<\/a><\/noindex><\/p>\n

Reminder:<\/b> For all readers of \u00abHabr\u00bb \u2014 a discount of 10,000 rubles when signing up for any Skillbox course using the promo code \u00abHabr\u00bb.<\/i><\/p>\n

Skillbox recommends:<\/b> Online educational course Java Developer<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don\u2019t Repeat Yourself)<\/h3>\n

\nA fairly simple principle, the essence of which is clear from the name: 'Do not repeat yourself.' For a programmer, this means the necessity to avoid duplicated code, as well as the opportunity to use abstraction in work.<\/p>\n

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 should be transformed into a public constant.<\/p>\n

This is necessary to simplify the code and make its maintenance easier, which is the primary goal of OOP. One should also avoid excessive combining, as the same code may not pass checks for both OrderId and SSN.<\/p>\n

Encapsulation of Changes<\/h3>\n

\nThe software products of most companies are constantly evolving. This means changes need to be made to the code, and it must be maintained. You can simplify your life with encapsulation. This will allow for more efficient testing and maintenance of the existing codebase. Here is one example<\/a><\/noindex>.<\/p>\n

If you're coding in Java, then by default, assign private to methods and variables<\/a><\/noindex>.<\/p>\n

The Open\/Closed Principle<\/h3>\n

\nThis principle can easily be 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 they can allow their behavior to be changed without altering the source code.<\/p>\n

The principle is important when changes in the source code require revision, unit testing, and other procedures. Code that adheres to the open\/closed principle does not change when extended, making it significantly less problematic.<\/p>\n

Here's an example of code that violates this principle.<\/p>\n

\"10
\n
\nIf any changes are required, it will take a lot of time because all parts of the code connected to the needed fragment will have to be changed.<\/p>\n

By the way, the principle of openness-closure is one of the SOLID principles.<\/p>\n

Single Responsibility Principle (SRP)<\/h3>\n

\nAnother principle from the SOLID set. It states that \"there is only one reason for a class to change.\" A class is responsible for only one task. It may have several methods, but each is used solely to solve the overall task. All methods and properties should serve only that purpose. <\/p>\n

\"10
\n
\nThe value of this principle is that it weakens the connection between individual software components and the code. If more than one functionality is added to a class, it introduces a link between two functions. Thus, if one is changed, the chances of damaging the second, related to the first, are high. This means an increase in testing cycles to identify all problems in advance.<\/p>\n

Dependency Inversion Principle (DIP)<\/h3>\n

\n\"10
\n
\nThe example above shows code where AppManager depends on EventLogWriter, which is closely tied to AppManager. If a different way is needed to show a notification, whether it be push, SMS, or email, the AppManager class must be changed.<\/p>\n

The problem can be solved using DIP. Instead of AppManager, we request EventLogWriter, which will be introduced through the framework.<\/p>\n

DIP allows for the easy replacement of individual modules with others by changing the dependency module. This enables the modification of one module without affecting the others.<\/p>\n

Composition over Inheritance<\/h3>\n

\n\"10There are two main ways to reuse code: inheritance and composition, each with its advantages and disadvantages. Composition is usually preferred because it is more flexible.<\/p>\n

Composition allows for changing the behavior of a class at runtime by setting its properties. While implementing interfaces, polymorphism is used, providing a more flexible implementation.<\/p>\n

Even \"Effective Java\" by Joshua Bloch advises favoring composition over inheritance.<\/p>\n

Liskov Substitution Principle (LSP)<\/h3>\n

\nAnother principle from the SOLID toolkit states that subtypes should be substitutable for their supertype. This means that methods and functions that work with a superclass should be able to work seamlessly with its subclasses.<\/p>\n

LSP is related to both the single responsibility principle and the principle of interface segregation. If a class provides more functionality than its subclass, the latter will not support some functions, violating this principle.<\/p>\n

Here is a piece of code that contradicts the LSP.<\/p>\n

\"10
\n
\nThe method area(Rectangle r) calculates the area of a Rectangle. The program will crash upon executing Square since Square is not a Rectangle here. According to the LSP, functions that use references to base classes should be able to use objects of derived classes without additional instructions.<\/p>\n

This principle, which is a specific definition of a subtype, was proposed by Barbara Liskov in 1987 at a conference in her keynote titled 'Data Abstraction and Hierarchy' \u2014 hence its name.<\/p>\n

Interface Segregation Principle (ISP)<\/h3>\n

\nAnother SOLID principle states that an interface that is not used should not be implemented. Adhering to this principle helps the system remain flexible and suitable for refactoring when changes to the logic are made.<\/p>\n

This situation most often occurs when the interface contains multiple functionalities, yet the client only needs one of them.<\/p>\n

Since writing an interface is a challenging task, modifying it after completion without breaking anything will be problematic.<\/p>\n

The advantage of the ISP in Java is that all methods must be implemented first, and only then can they be used by classes. Therefore, the principle enables a reduction in the number of methods.<\/p>\n

\"10
\n <\/p>\n

Programming for interfaces, not implementations<\/h3>\n

\nThis is clear from the name. Applying this principle leads to the creation of flexible code that can work with any new implementation of the interface.<\/p>\n

You should use the interface type for variables, return types, or method argument types. For example, use SuperClass instead of SubClass.<\/p>\n

That is:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

Not:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Here is a practical implementation of what is stated above.<\/p>\n

\"10
\n <\/p>\n

Principle of Delegation<\/h3>\n

\nA 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.<\/p>\n

The advantage of this principle is the absence of code duplication and relatively simple behavior modification. It is also applicable for event delegation.<\/p>\n

\"10
\n
\nAll these principles allow for writing more flexible, elegant, and reliable code with high cohesion and low coupling. Of course, theory is great, but in order for developers to truly apply the knowledge gained, practice is required. The next step after mastering OOP principles could be studying design patterns to solve common software development problems.<\/p>\n

Skillbox recommends:<\/b><\/p>\n