Turn: five design principles of OOD

I recently encountered a problem with the design principles of OOD during the written examination. From http://www.cnblogs.com/xwang/archive/2009/01/13/1374652.html

Five Principles of OOD:

(1): SRP, single responsibility principle (only Buddha should assume the responsibility to publish xuanmiao secrets ...)

A class should have only one reason for change.

Because every responsibility is an axis of change, when the demand changes, this change will be reflected in the changes in the class responsibility. if a class assumes more than one responsibility, there are multiple reasons for its change. if a class has too many responsibilities, these responsibilities are coupled together.

Note: only when a change occurs does the changed axis have practical significance. If there is no indication, applying SPR or any other principles is unwise.

(2): OCP, open-closed principle (two doors, one divided horizontally into two parts, so that each part can be kept open or closed independently)

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified.

OCP has two main features:

(1): open for extension: it means that the module behavior can be expanded. When the application needs to change, we can expand the module, make it meet the new behaviors of those changes. In other words, we can change the functions of the module.

(2): closed for modification: you do not need to modify the source code or binary code of the module when extending the module behavior, whether it is a connectable library, do not modify the DLL or EXE file.

So how to implement it? The answer is abstraction. because the module depends on abstraction, it can be closed for changes. At the same time, it can expand the behavior of this module by deriving from this abstract body.

Two commonly used design modes are: STRATEGY Mode and template method mode.

In fact, it is impossible to completely close, so we must treat this problem with a strategy. That is to say, the designer must choose which changes should be closed for the module designed by him, he must first guess the most likely types of changes, and then construct an abstraction to isolate them.

Conclusion: OCP is the core of object-oriented design. Following this principle can bring huge benefits of object-oriented technology: flexibility, reusability and maintainability. it is not a good idea to abstract every part of an application. the correct approach is: the designer should only abstract those parts that present frequent changes in the program.

(3): LSP and Lishi replacement principles

Subtypes must be able to replace their base types ).

Barbara Liskov wrote this principle for the first time in 1988. She said: if there is a T-type object O2 for every object O1 of type S, so that in all P programs written for T, after O2 is replaced with O1, the behavior function of P remains unchanged, and S is the child type of T.

LSP clearly pointed out that the IS-A relationship in OOD is in terms of the behavior mode, and the behavior mode can be reasonable assumptions, is the customer program dependent. from this we can see: A lot of things may be on the surface of the IS-A, but in fact not.

Design By Contract DBC can support LSP well.

(4) DIP, depending on the inverted principle (it is not necessary to let the major interests of the country depend on the many possibilities that will shake the weak will of mankind)

Two main principles of DIP:

(1): High-Level modules should not depend on low-level modules, both of which should depend on abstraction;

(2): Abstraction should not depend on details, but on abstraction;

Booch once said: "All well-structured object-oriented architectures have clear hierarchical definitions, and each layer provides services in a group through a well-defined and controlled interface. "In fact, each higher level declares an abstract interface for the required service, and the lower level implements these abstract interfaces. each high-level class uses the next layer through this abstract interface, so that the High-level class does not depend on the lower layer, but the lower layer depends on the abstract service interface declared in the higher layer.

The inversion here is not only the inversion of dependency, but also the inversion of interface ownership. We usually think that tool libraries have their own interfaces. however, when DIP is applied, we find that customers often have abstract interfaces, and their service providers derive from these abstract interfaces. this is also the famous Hollywood principle: "Don't call us, we'll call you. (Do not call us, we will call you )".

Dependent on abstraction. This is a simple statement. The suggestion of this heuristic rule should not depend on a specific class. That is to say, all dependencies in the program should end with abstraction or interfaces. it reminds us to encode it like this: a, no variable should hold a reference pointing to a specific class; B, no class should be derived from a specific class; c, no method should overwrite any implemented methods in any of its base classes.

(5) ISP and interface isolation principles

Fat classes will lead to abnormal and harmful Coupling Relationships between their customer programs. When a customer program requires a change to the fat class, it will affect all other customer programs. therefore, the customer program should only rely on the methods actually called. this goal can be achieved by decomposing the fat class interface into multiple client-specific interfaces. each customer Program-specific interface only declares the functions called by specific customers or customer groups. Then, the fat class can inherit all the interfaces specific to the customer program, and implement them. this removes the dependency between the client program and the methods they do not call, and makes the client program independent of each other.