Eight principles of programming that can make your life easier
One of the main problems in software development is the struggle with the increasing complexity of the system. The solution to this problem is involved since the first programs appeared. The results are languages that are increasingly simplifying the interaction with the machine, programming paradigms like OOP, patterns. In this article, the principles of programming will be considered to reduce the complexity and facilitate system maintenance.
1. Encapsulate what changes.
This is the basis of the entire PLO. It is necessary to identify components that may change, and separate them from the part of the system that will remain unchanged. Encapsulation will allow you to change or expand the selected components without changing the rest of the system. The main problem here is how best to split the application into parts. All design patterns deal with the answer to this question.
2. Prefer composition to inheritance.
During composition, the behavior is not inherited, but is provided for use by the correctly selected object. The same composition allows you to change the behavior of the object, if it is connected not directly, but through the interface (see the following principle). Naturally, it is fanatical to use composition everywhere and it would be unwise to completely abandon inheritance.
3. The code should depend on abstractions, and not on specific implementations.
High-level components should not depend on low-level components, and they both should depend on abstractions. The authors of this book call it the principle of dependency inversion (Inversion of Control, IoC) . It is better to allocate the class contract in the interface, and then implement it. For example, instead of:
')
need to write:
Accordingly, in accessors, method calls should use abstractions, not implementations. Now, if you need to change the behavior of the list to biconnected, it is enough to change only one line:
4. Aim for weak connectivity of interacting objects.
The less objects know about each other, the more flexible the system. One component does not need to know about the internal structure of another.
5. Classes should be open for expansion, but closed for change.
This is the so-called principle of " openness / closeness ." In different periods of time it was implemented in different ways. Bertrand Meyer proposed in his book not to change the created implementation of the class, and, if necessary, to make changes, to extend the class by creating heirs. Later, the idea was put forward to use interfaces, the implementations of which can be polymorphically replaced with one another, if necessary.
6. Interact with close friends only.
This is the principle of minimal awareness . When designing a class, one should pay attention to the number of classes with which its interaction will occur. The smaller such classes, the more flexible the system.
7. Do not call us - we will call you.
Or the Hollywood principle . According to Fowler , this is a synonym for IoC principle. According to the idea, high-level components (eg, interfaces) are defined as low-level components (implementations), how and when to connect to the system. The authors of Head First Design Patterns admit that, according to this principle, low-level components can participate in calculations without generating dependencies with high-level components, and this is the difference from more rigid IoC.
8. The class (or method) should have only one reason for the change.
This is the so-called principle of one duty . The more reasons for change, the greater the likelihood of change. And change is the cause of a lot of problems The principle indicates that the class (as well as the method) should be allocated only one duty. For example, in a well-designed system with a three-layer architecture: one DAO method makes exactly one request to the base, one service method performs exactly one business logic task, one controller method calls the service exactly once.
Almost all the principles intersect with each other, all the tasks are the same - reducing the complexity of the system and, as a result, the lives of programmers. I want to believe that someone's life will become easier after reading =)
Upd .: Gentlemen, who refer to Head First Java Patterns: this is not the first and not the last book in which these principles were described. This can be seen by reading, for example:
Martin Fowler, Patterns of Enterprise Application Architecture
Kent Beck, Implementation Patterns
Andrew Hunt, David Thomas, The Pragmatic Programmer
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
1. Encapsulate what changes.
This is the basis of the entire PLO. It is necessary to identify components that may change, and separate them from the part of the system that will remain unchanged. Encapsulation will allow you to change or expand the selected components without changing the rest of the system. The main problem here is how best to split the application into parts. All design patterns deal with the answer to this question.
2. Prefer composition to inheritance.
During composition, the behavior is not inherited, but is provided for use by the correctly selected object. The same composition allows you to change the behavior of the object, if it is connected not directly, but through the interface (see the following principle). Naturally, it is fanatical to use composition everywhere and it would be unwise to completely abandon inheritance.
3. The code should depend on abstractions, and not on specific implementations.
High-level components should not depend on low-level components, and they both should depend on abstractions. The authors of this book call it the principle of dependency inversion (Inversion of Control, IoC) . It is better to allocate the class contract in the interface, and then implement it. For example, instead of:
')
private ArrayList < String > someList = new ArrayList < String > ();need to write:
private List < String > someList= new ArrayList < String > ();Accordingly, in accessors, method calls should use abstractions, not implementations. Now, if you need to change the behavior of the list to biconnected, it is enough to change only one line:
private List < String > someList= new LinkedList < String > ();4. Aim for weak connectivity of interacting objects.
The less objects know about each other, the more flexible the system. One component does not need to know about the internal structure of another.
5. Classes should be open for expansion, but closed for change.
This is the so-called principle of " openness / closeness ." In different periods of time it was implemented in different ways. Bertrand Meyer proposed in his book not to change the created implementation of the class, and, if necessary, to make changes, to extend the class by creating heirs. Later, the idea was put forward to use interfaces, the implementations of which can be polymorphically replaced with one another, if necessary.
6. Interact with close friends only.
This is the principle of minimal awareness . When designing a class, one should pay attention to the number of classes with which its interaction will occur. The smaller such classes, the more flexible the system.
7. Do not call us - we will call you.
Or the Hollywood principle . According to Fowler , this is a synonym for IoC principle. According to the idea, high-level components (eg, interfaces) are defined as low-level components (implementations), how and when to connect to the system. The authors of Head First Design Patterns admit that, according to this principle, low-level components can participate in calculations without generating dependencies with high-level components, and this is the difference from more rigid IoC.
8. The class (or method) should have only one reason for the change.
This is the so-called principle of one duty . The more reasons for change, the greater the likelihood of change. And change is the cause of a lot of problems The principle indicates that the class (as well as the method) should be allocated only one duty. For example, in a well-designed system with a three-layer architecture: one DAO method makes exactly one request to the base, one service method performs exactly one business logic task, one controller method calls the service exactly once.
Almost all the principles intersect with each other, all the tasks are the same - reducing the complexity of the system and, as a result, the lives of programmers. I want to believe that someone's life will become easier after reading =)
Upd .: Gentlemen, who refer to Head First Java Patterns: this is not the first and not the last book in which these principles were described. This can be seen by reading, for example:
Martin Fowler, Patterns of Enterprise Application Architecture
Kent Beck, Implementation Patterns
Andrew Hunt, David Thomas, The Pragmatic Programmer
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Source: https://habr.com/ru/post/140827/
All Articles