Object-Oriented Design Model

First, we need to know what the mode is:

In short: while people constantly discover problems and find solutions to problems in their own environments, discovering different problems actually involves a common nature. These essence is what we call models.

Therefore, the model is representative.

In the Object-Oriented field, the earliest modeling method research was published in 1995 by Gang of Four (gof, Erich Gamma, Richard Helm, Ralph Johnson, John vlissides ).

Design patterns, but the true origins of the pattern are from the works of Christopher Alexander, the architect of architectural engineering.

When developing a software system, we must solve two core problems: maintainability and reuseability ); the best way to help us solve these two problems is to use the design mode,

But when learning and using design patterns, we cannot simply copy them. What should we do if we have our own ideas? This is a well-known design principle that guides the formation of design patterns:

Before explaining the design principles, we should further discuss two core issues:

1. maintainability

People with years of development experience will feel that the maintenance time spent on a system is much longer than the development time of the system. According to statistics, the number of failed projects at home and abroad is as high as 60%;

The following describes Rober C. Martin's guidance, which leads to four main reasons for low maintainability of a system:

1 ). too stiff: adding a new performance to the system not only means adding an independent new module, but also affects many other modules, as a result, a simple function may be far away

2). Too fragile: modifying a location in the system often leads to faults in another location that is irrelevant.

3 ). low Reuse Rate: Sometimes we find that a piece of code, functions, and modules can be reused in a new module, but we find that these existing codes always rely on other things, it is difficult to separate them. In the end, you give up reuse, or look for Ctrl + S, V

4). High Viscosity:

Design goals:

1). Scalability: new performance can be easily added to the system without causing other problems, that is, the opposite of "too stiff ".

2). pluggable: it is easy to extract a class and add a class with the same interface, that is, the opposite of "high viscosity ".

3). Flexibility: the code can be modified smoothly without affecting many other modules, that is, the opposite side of "too fragile ".

 

Object-Oriented Design Principles:

1): "open-closed" principle (open-closed principle, OCP ):

A software entity should be open to extensions and closed to modifications (software entities shocould be open for extension, but closed for modification). That is, classes are extended without being modified, therefore, it is also referred to as the "variability encapsulation principle ".

2): liskov substitution principle, LSP ):

If every object O1 in class T1 has the object O2 of class T2, so that all program P containing T1 is converted to O2 in all object O1, the behavior of program P is not changed, then class T2 is a subclass of class T1, that is, the behavior of the parent class must be suitable for the subclass, but the replacement in turn is not valid. If the relationship between Class A and Class B violates the Lee's replacement principle, you can choose one of the following two reconstruction schemes:

① Create a new abstract class C, which is the superclass of A and B. Move the common behaviors of A and B to C to solve the inconsistency between the behaviors of A and B; ② change the inheritance relationship from B to a to the delegate relationship.

3): Dependency inversion principle (DIP ):

High-level modules should not depend on low-level modules, and abstraction should not depend on details.

4): interface segregation principle (ISP ):

It is better to use multiple interfaces than to use a single interface. From the client perspective, the dependency of one class on the other class should be built on the smallest interface. If the client only needs one method, it should provide the method to the client, instead of providing unnecessary methods, the interface is provided to make a commitment to the client, but too much commitment will cause unnecessary burden on system maintenance.

5): Composition/aggregation Reuse Principle, CARP ):

Try to use combination and aggregation, instead of inheritance.

6): Law of Demeter (D3S ):

An object should know as little as possible about other objects, that is, it only communicates with direct friends and does not talk to strangers.

7): single responsibility principle (single responsibility principle, SRP ):

A class should have only one reason for its change. If a class has multiple reasons for its change, it should be split into multiple classes.

 

Object-Oriented Design Model:

According to the design principles,