Two days ago, when I talked to a friend about the OO design principles, I had a deeper understanding of the design model. Here I will summarize it and share it with you.
OO (Object-Oriented) Object-oriented
The Object-Oriented Method (OO) is a system Method that applies the object-oriented Method to the software development process and guides development activities, the OO (Object-Oriented) method is a methodology based on the concept of "Object. An object is an encapsulation body composed of data and permitted operations. It directly corresponds to an objective object. An object class defines a group of objects of similar nature. Each inheritance is a way to share attributes and operations of classes with hierarchies. The so-called object-oriented is based on the object concept, object-centered, class and inheritance as the construction mechanism, to understand, understand, portray the objective world and design, and build the corresponding software system.
OO design goals:
- Scalability: with new requirements, new performance can be easily added to the system without affecting the existing performance or bringing new defects.
- Modifyable: When the code of a system is to be modified, the existing structure of the system is not damaged, and other parts are not affected.
- Alternative: some code in the system can be replaced with other classes of the same interface, without affecting the system.
Design Principles of the design model:
- The principle of "openness-closeness:
The core principles of the design pattern. Software entities (classes, modules, and functions) are open for extensions and closed for modifications. The key to achieving the principle of openness and closure is abstraction. In the "open-close" principle, abstract classes or interfaces cannot be modified. Specific implementation classes are allowed to be extended. abstract classes and interfaces play an extremely important role in the "open-close" principle.
- Encapsulation change principle:
This is the best implementation of the "open-close" principle .. do not place your variable factors in multiple classes, or scatter them in every corner of the program .. you should encapsulate variable factors .. do not enclose variable factors .. the best solution is to block your variable factors !! Avoid the appearance of ultra-large, ultra-long, and ultra-long methods !! Adding an artistic atmosphere to your program and making the program artistic is our goal !!
- Lee's replacement principle:
Where any base class can appear, subclass can also appear.
- Dependency reversal principle:
It depends on abstraction rather than specific implementation. Abstraction should not depend on details, and details should depend on abstraction. Interface-oriented programming should be avoided.
- Single responsibility principle:
A class should have only one reason for its change.
- Interface isolation rules:
In order to achieve as little coupling as possible, we need to use interfaces to define classes and use interfaces to constrain classes. To meet the requirements of the dimit rule, it is best to implement the interface isolation rule. It is better to use multiple special interfaces than to use a single total interface. From the perspective of a customer class, the dependence of one class on another class should be based on the smallest interface. An interface should represent a role rather than multiple roles. Multiple actors can play one role at a time, just like Sun Wukong's child.
- Synthesis/aggregation principles:
We should try to use the synthesis/aggregation principle instead of the inheritance relationship to achieve the purpose of software reuse. Aggregation is used to indicate "ownership" or the relationship between the whole and the part, while synthesis is used to indicate a much stronger "ownership" relationship. In a compositing relationship, the partial and overall lifecycle are the same. Synthesis is like the "finished product". Splitting is bad.
- Dimit rules:
In the system, try not to interact with other classes to reduce the coupling between classes. An object should have as little understanding as possible about other objects. The two classes do not need to communicate directly. They can forward the call through a third party (abstract). This abstract third party can be a facade or a mediator, it is even an abstract class or interface. modules must be independent and encapsulated. They only rely on public APIs for communication. As long as possible, a class should be designed as a constant class, its attributes should be private. If a class has too many public access permissions, you can use multiple classes to separate the private and public methods of a class.
Aggregation ):
This is a loose relationship between objects. For example, the relationship between a computer and its peripheral devices.
Used to indicate the relationship between ownership or the whole and part.
Composition ):
This is a very strong relationship between objects. For example, the relationship between a tree and its leaves.
In a synthesis, the entire lifecycle is the same. A new merged object is fully composed
Part of the permission. Including their creation and destruction.
Summary:
Aggregation:
- Aggregation sometimes does not depend on parts, and sometimes does not
- Some can exist independently of aggregation.
- If some of them are lost, aggregation will give people an incomplete feeling.
- Some ownership can be shared by several aggregates, such as printers.
Merging:
- Part of a time can only belong to one
- A unique component responsible for processing all its parts-this means responsible for their creation and destruction
- If some of the responsibilities are undertaken by other users, the roles can be relaxed.
- If a component is destroyed, it must destroy all the parts or transfer their rights to other objects.
Problems solved by the design model:
Create an object by displaying the specified class:
Related design patterns: simple factory, factory method, and abstract factory.
Tight coupling:
Related design patterns: Abstract Factory, command mode, appearance mode, intermediary mode, observer mode, and responsibility chain mode.
Dependency on object representation or implementation:
Related design patterns: Abstract Factory, Bridge Mode, memorandum mode, proxy mode, etc.
Extend the function by generating sub-classes:
Related design modes: Bridge Mode, responsibility chain mode, combination mode, decoration mode, observer mode, and Policy mode.
Classes can be easily modified:
Related design modes: adapter mode, decoration mode, and visitor mode.
Algorithm dependency:
Related design modes: generator mode, iteration mode, policy mode, template method mode, and visitor mode.
Dependencies on software and hardware environments:
Related design patterns: Abstract Factory patterns, bridging patterns, etc.
Reference: http://ankye1234.blog.163.com/blog/static/964828920075444512292/
