design mode source code
Design mode source code
1 single function principle
The single function principle (responsibility principle) stipulates that each class should have a single function, and that the function should be fully encapsulated by this class. All its services (this class) should be closely parallel to the function (functionally parallel, meaning no dependencies).
Onlookers design mode (1)--single function principle
2 Richter Replacement principle
In object-oriented program design, the Richter substitution principle (Liskov Substitution principle) is a special definition of a subtype. It was first presented in a speech by Barbara Liskov (Barbara Liskov) in a conference entitled "Abstraction and Hierarchy of data" in 1987.
The content of the Richter substitution principle can be described as: "A derived class (subclass) object can be substituted for its base class (superclass) object to be used." "The above is not the original text of Liskov, but the interpretation of the original from the Robert Martin (Robert Martin)." The original text is:
Let q (x) is a property provable about objectsx of Typet. Thenq (y) should be true for Objectsy of TypeS Wheres is a subtype OfT.
Barbara Liskov and Zhou Yijien (Jeannette Wing) published their paper in 1994 and proposed the principle of Liskov substitution. ----Wikipedia
Richter replacement principle my personal understanding is that in an inheritance relationship, if the object of the parent class is replaced with the object of the subclass, the behavior of his original execution remains the same, then the program conforms to the Richter scale substitution principle, otherwise it violates the Richter scale substitution principle.
"Onlookers" design mode (2)--The Richter replacement principle (Lsp,liskov Substitution Principle)
3 Dependency Inversion principle
In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling software module S. When following this principle, the conventional dependency relationships established from high-level, policy-setting mo Dules to low-level, dependency modules is reversed, thus rendering high-level modules independent of the low-level module Implementation details. The principle states:
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
The principle inverts the some people may think about object-oriented design, dictating that both high-and low-level Objects must depend on the same abstraction.
----WIKIPEDIA
Interpretation (readers can try their own translation, personal feeling the second sentence is not good, but quite interesting):
In object-oriented program design, the dependency inversion principle refers to the special form of decoupling software module. Traditional dependencies are built at a high level, and specific policy settings are applied at low levels. Using the dependency inversion principle, the upper layer is independent of the underlying implementation details and the dependency is inverted, making the low-level module dependent on the abstraction of the high-order module.
The principle stipulates that:
A. High-level modules should not be dependent on low-layer modules, both of which rely on abstract classes.
B. Abstract classes should not be dependent on implementation details, and implementation details should be dependent on abstraction.
This principle overturns some people's understanding of object-oriented programming, such as: both the upper and lower layers should rely on the same abstraction.
"Onlookers" design mode (3)-Dependency inversion principle (dip,dependence inversion Principle)
4 Interface Isolation principle
The interface Isolation principle (English: Interface-segregation principles, Abbreviation: ISP) indicates that no client (client) should be forced to rely on the method it does not use. The interface Isolation principle (ISP) splits very large, bloated interfaces into smaller and more specific interfaces so that customers will only need to know the methods they are interested in. This narrowing of the interface is also known as the role interface (roles interfaces). The purpose of the Interface Isolation principle (ISP) is for the system to unlock the coupling, making it easy to refactor, change, and redeploy. ----WIKIPEDIA
An individual's understanding of the principle of interface isolation is:
When designing an interface, try to ensure that the classes that implement the interface are as consistent as possible with the methods in the interface, avoiding excessive design of the methods in the interface, resulting in the need to implement multiple, completely useless methods in their implementation classes (which can cause redundancy and confusion in the code).
"Onlookers" design mode (4)--Interface Isolation principle (Isp,interface segregation Principle)
5 Dimitri Rule (minimum knowledge of criteria)
The Dimitri (Law of Demeter, abbreviated LOD), also known as the "least knowledge principle (Principle of Least Knowledge)", is a design guideline for software development, especially for object-oriented programming. The Dimitri Law is a specific case of loose coupling. The principle is that Northeastern University was invented at the end of 1987 and can be summarized simply in one of the following ways:
1. Each unit can only have limited knowledge of the other units: only those elements that are closely linked to the current unit;
2. Each cell can only talk to its friends: can't talk to unfamiliar units;
3. Just talk to your direct friends.
The name of this principle derives from the goddess of agriculture in Greek mythology, the solitary Artemis.
Many object-oriented programming languages use "." Represents the parsed operator of the field of an object, so the law of the Artemis can simply be stated as "using only one. Operator". Therefore, A.b.method () violates this law, and a. Method () does not violate this law. A simple example is that a person can command a dog to walk (walk), but should not direct the dog's legs to walk, it should be the dog to command control of its legs how to walk. ----Wikipidia
Personal Understanding:
Object-oriented program design, object and object as far as possible independent of each other, the specific object of the behavior of the specific object to complete, rather than one object to specify another object to implement the behavior and is specific behavior. Dimitri Law, the core of the idea is that when we design, we try to avoid the coupling between classes and classes, weakening coupling relationship can improve the reuse rate, but in this case, will produce intermediate jump class, resulting in a complex system. As far as possible in the actual use of the process in order to ensure readability and low complexity, according to Dimitri Law to weaken the coupling between classes and classes (high cohesion, low coupling). "Onlookers" design pattern (5)--Dimitri Law (Lod,law of Demeter) or least known principle (Least knowledge Principle)
6 Opening and closing principle
In the field of object-oriented programming, the opening and closing principle stipulates that "objects in software (classes, modules, functions, etc.) should be open to extensions, but closed for modification", which means that an entity is allowed to change its behavior without changing its source code. This feature is particularly valuable in a production environment where changing the source code requires code review, unit testing, and the like to ensure the quality of the product's use. Code that follows this principle does not change as it expands, so the process is not required.
The naming of open and close principle is applied in two ways. Both of these approaches use inheritance to solve obvious dilemmas, but their purpose, technology, and results are different. ----WIKIPEDIA
Individual understanding of the open/closed principle:
The opening and closing principle is equivalent to a programmatic principle, the promotion class should be in the design after the completion of the expansion of the way to adapt to the new business needs, rather than through the modification of the way to adapt to the new requirements, such a design more flexible and stable. The previous five principles are the concrete realization of the open and closed principle idea.
"Onlookers" design mode (6)--opening and closing principle (open/closed Principle)
"Onlookers" design mode (28)--Summary of the six principles of design pattern
