The power of 7 object-oriented designs

Why should you use object-oriented programming? Today, we explain why we use object-oriented and what the benefits of it are by talking about a few design principles.

A single principle of responsibility:

Full name: "Single-responsibility Principle" Object-oriented design

Description: In the case of a class, you should focus only on doing one thing and only a reason that causes it to change. The so-called duty, we can understand his function, is that the design of this kind of function should be only one, not two or more. It can also be understood that the reason for the reference change, when you find that there are two changes that will require us to modify the class, then you have to consider the withdrawal of this class. Because responsibility is an axis of change, when demand changes, the change reflects the change in the class's responsibilities.

Note Points using SRP:

1, a reasonable class, there should be only one cause of its change, that is, a single duty;

2. It is unwise to apply the SRP or other principles without any indication of change;

3, in the actual change in demand should be applied to the principles of SRP to reconstruct the code;

4. The use of test-driven development will force us to separate unreasonable code before the design stinks;

5. If the test does not force separation of duties, the stench of rigidity and fragility becomes strong, then the code should be refactored with the facade or proxy pattern; SRP Pros: Eliminate coupling and reduce code rigidity due to changes in demand.

Second, the principle of substitution on the Richter scale

Full name: "Liskov Substitution Principle"

Description: Subtypes must be able to replace their base types. A software entity if you are using a base class, then when you replace the base class with a subclass that inherits the base class, the behavior of the program does not change. The software entity does not perceive the difference between a base class object and a subclass object.

Advantages: It is easy to implement the interchange of subclasses under the same parent class, and the client can be unaware.

Iii. the principle of dependency inversion

Full name: "Dependence inversion Principle"

Description: To rely on abstraction, do not rely on specifics. The client relies on abstract coupling.

Abstraction should not be dependent on detail; details should be dependent on abstraction;

To program for the interface, do not program for implementation.

Pros: Using the dependencies created by traditional procedural programming, the policy relies on detail, which is bad because the strategy is affected by the change in detail. The dependency inversion principle makes the detail and strategy dependent on the abstraction, and the stability of the system determines the stability.

How to do dependency inversion?

Coupling in an abstract way is the key to relying on the reversal principle. Abstract coupling relationships always involve concrete classes inheriting from abstract classes, and it is necessary to ensure that any reference to the base class can be converted to its subclasses, so the Richter substitution principle is based on the principle of reversal.

Although coupling at the level of abstraction is flexible, it also brings additional complexity, and if the likelihood of a specific class change is very small, then the benefits of an abstract coupling can be very limited, which can be better with concrete coupling.

Hierarchical: All well-structured object-oriented architectures have a clear hierarchical definition, with each level providing a cohesive set of services to the outside through a well-defined, controlled interface.

Dependent on abstraction: the recommendation does not depend on a specific class, that is, all dependencies in a program should terminate in an abstract class or interface. Try to do the following:

1. Any variable should not hold a pointer or reference to a specific class.

2. No class should derive from a specific class.

3. No method should overwrite an already implemented method in any of its base classes.

Iv. Principle of interface Isolation

Full name: "Interface segregation Principle"

Description: An interface that uses multiple-specificity features is always better than using a single total interface. From the perspective of a customer class, the dependency of a class on another class should be based on the minimum interface. An overly bloated interface is a pollution to the interface and should not force customers to rely on methods that they do not use.

Pros: When a software system function is extended, the modified pressure is not propagated to other objects.

How to implement the principle of interface isolation

Users should not be forced to rely on methods that they do not use.

1, the use of delegated separation interface.

2, the use of multi-inheritance separation interface.

V. Principles of Dimitri

Full name: "Law of Demeter"

Description: The object and object should be associated with as few methods as possible to avoid the intricate relationships.

How to implement the Dimitri law?

The main purpose of Dimitri Law is to control the overload of information, in the application of the system design should pay attention to the following points:

1) in the division of classes, a class with weakly coupled should be created. The weaker the coupling between classes, the more beneficial it is to reuse.

2) in the class structure design, each class should minimize the member's access rights. A class should not public its own property, but should provide a way to give value and assignment to the outside world to access its properties indirectly.

3) in the design of the class, whenever possible, a class should be designed to be invariant class.

4) on references to other objects, a class's reference to other objects should be minimized.

Vi. Open-closure principle

Full name: "Open-closed Principle"

Description: Open for extension, close for modification.

Advantages: The system designed according to the OCP principle reduces the coupling between each part of the program, and its adaptability, flexibility and stability are better. When existing software systems need to add new functionality, there is no need to modify the abstraction layer as the basis of the system, simply attach the new module on the original basis to achieve the required functionality. The added new modules have no effect on the original modules or have minimal impact, so there is no need to re-test the original modules.

How to implement the "open-close" principle?

In object-oriented design, it is not allowed to change the abstraction layer of the system, but the implementation layer of the system is allowed to extend. In other words, define a once and for all abstract design layer, allowing as many behaviors as possible to be implemented at the implementation level.

The key to solving the problem lies in abstraction, which is the first core essence of object-oriented design.

The abstraction of a thing is essentially a generalization of its essence. Abstract let us seize the most important things, from a higher level to think. This reduces the complexity of thinking, and we don't have to think about that much at the same time. In other words, we encapsulate the nature of things and see no details.

In object-oriented programming, by means of abstract classes and interfaces, the characteristics of specific classes are defined as abstract layers, relatively stable, without change, so as to satisfy the "close to modify", and the concrete classes derived from abstract classes can change the behavior of the system, thus satisfying the "open to extended".

When you extend an entity, you do not have to change the source code or the binaries of the software. The key is abstraction.

Synthetic recovery principles:

Full Name: (Composite reuse PRINCIPLE,CRP)

Try to use object combinations instead of inheritance to achieve reuse.

Combination/Aggregation multiplexing principle (composite/aggregate reuse Principle CARP). Both composition and aggregation are one of the Association (association) relationships in object modeling. Aggregation represents the relationship of the whole to the part, which means "contains", The whole is made up of parts, and the part can be separated from the whole as an individual existence. Combination is a stronger aggregation, part of the whole, and indivisible, part can not be separated from the whole and exist alone. In synthetic relationships, as part of the life cycle of the whole, the combined new objects completely dominate their constituent parts, including their creation and destruction. A composition object in a synthetic relationship cannot be shared with another composition relationship.

Combination/aggregation and inheritance are the two basic ways to achieve reuse. The principle of synthetic multiplexing is to use composition/aggregation as much as possible, rather than using inheritance.

You should use an inheritance relationship only if the following conditions are all met.

1. Subclasses are a special kind of superclass, not a role of superclass, that is to say "has-a" and "is-a". Only the "is-a" relationship conforms to the inheritance relationship, and the "has-a" relationship should be described using aggregations.

2. It is never possible to change a subclass to a subclass of another class. Do not use inheritance if you are not sure whether it will become another subclass in the future.

3. Subclasses have the responsibility of extending the superclass, rather than having the responsibility of displacing or unregistering out-of-class. If a subclass needs to displace the behavior of the superclass a lot, then this class should not be a subclass of the superclass.

A common cause of incorrect use of inheritance rather than composition/aggregation is to mistakenly treat "has-a" as "is-a". " Is-a "represents a class as one of the other classes, while" has-a "means that a class is a role of another class, not a special kind of another class.

The power of 7 object-oriented designs