Article directory
"Design Pattern" Six Principles Series Links: "Design Pattern" One of the Six Principles: Summary of Single
Responsibility Summary of Principles Four of the Six Principles of "Design Patterns": Summary of the Principle of Interface Segregation Five of the Six Principles of "Design Patterns": Summary of the Principle of Dependency Inversion
The six principles reflect the underlying logic of many programming: high cohesion, low coupling, object-oriented programming, interface-oriented programming, abstract-oriented programming, and ultimately achieve readability, reusability, and maintainability.
The six principles of design patterns are:
- Single Responsibility Principle: Single Responsibility Principle
- Open Closed Principle: Open and Closed Principle
- Liskov Substitution Principle: Liskov Substitution Principle
- Law of Demeter: Law of Demeter (least known principle)
- Interface Segregation Principle: Interface Segregation Principle
- Dependence Inversion Principle: The principle
of dependency inversion combines the initials of these six principles (L is counted as one) is SOLID (solid, stable), which means the benefits of combining these six principles: establishing a stable, flexible , robust design.
This article introduces the sixth principle in SOLID: the principle of least knowledge.
1. Definition of Least Knowledge Principle (LOD)
The English translation of the minimum knowledge rule is: Law of Demeter, the abbreviation is LOD. The English translation is: The Least Knowledge Principle.
It originated from a research project called Demeter at Northeastern University in the United States in 1987. It was proposed by Ian Holland and popularized by Booch, one of the founders of UML. Later, it became widely known because it was mentioned in the classic book "The Pragmatic Programmer".
It is also called Dimit's law, which is not easy to remember. We'd better remember it as the minimum knowledge rule.
Regarding this design principle, let’s take a look at its most original English definition:
Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
translate to Chinese:
Each module (unit) should only know the limited knowledge (knowledge) of those modules that are closely related to it (units: only units “closely” related to the current unit). In other words, each module only "talks" with its own friends, not with strangers.
Transform the understanding again:
There should be no dependencies between classes that should not have direct dependencies; between classes that have dependencies, try to only rely on the necessary interfaces (that is, the "limited knowledge" in the definition).
2. What is "high cohesion"?
The so-called high cohesion means that similar functions should be placed in the same class, and dissimilar functions should not be placed in the same class. Similar functions are often modified at the same time and placed in the same class, the modification will be more concentrated, and the code is easy to maintain.
In fact, the single responsibility principle we mentioned earlier is a very effective design principle for achieving high code cohesion.
3. What is "loose coupling"?
The so-called loose coupling means that in the code, the dependencies between classes are simple and clear. Even if two classes have dependencies, a code change in one class will not or rarely cause code changes in the dependent class.
In fact, dependency injection, interface isolation, programming based on interface rather than implementation, and today's Dimit's law are all to achieve loose coupling of code.
4. Application examples
- For example, we designed the user management class UserManager to manage login, logout and other operations for the caller to call, but the caller does not understand the specific login and logout functions of writing and clearing the user cache.
Caller --> UserManager (user management class) --> UserCacheManager (user cache class)
-
Another example is the relationship between tenants, landlords (rooms) and intermediaries. The idea of code mode can be included. The tenant only needs to communicate with the intermediary. As for the information of the landlord (room), it can be managed by the intermediary. For example, the room information can be encapsulated into the intermediary class and a method can be provided.
-
Another example is the relationship between celebrities, commercial company activities (or fan meetings) and economic agents.
In short: the API provided by class A does not meet the needs of B, and needs to be combined repeatedly. At this time, an intermediate class C is needed to coordinate the relationship between A and B. C is the role of peacemaker (intermediary role).
reference:
"The Beauty of Design Patterns"
"Re-learning Java Design Patterns"
"Android source code design pattern analysis and actual combat"