Object-Oriented Design principles-principles and patterns

Original Author: Robert C. Martin

Original article: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

Reference page: http://www.objectmentor.com/resources/publishedArticles.html

Ii. Object-oriented Design Principles

1 The Open-Close principle (open and closed principle)

A module shoshould be open for extension but closed for modification.

A module should be open to extensions and closed to modifications.

This is the most important of all OO design principles. We should construct such a module so that it can be extended without modification. That is, we can change the module behavior without changing the module source code.

Polymorphism is the most basic way to achieve the principle of open and closed. The example can be found in any lecture mode or oo book.

2 The liskov substitution principle (liskov replacement principle)

Subclasses shoshould be substitutable for their base classes. subclasses shoshould be substitutable for their base classes.

Child classes should be able to replace their base classes.

This sentence is simply a nonsense syntax. In object-oriented languages, base class references can be passed into their subclasses, with rare exceptions. But it is not necessarily semantic. Let's look at the example below.

Class rectangle

{

Public:

Void setwidth (INT width );

Void setheight (INT height );

Int getheight ();

Int getwidth ();

}

Void squaretest (rectangle & rect)

{

Rect. setwidth (5 );

Rect. setheight (6 );

Assert (rect. getwidth () * rect. getheight () = 30 );

}

The above testCodeIt should be passed at any time.

Logically, a square is a type of rectangle and A is-a relationship. Therefore, it seems logical to derive the squre class from the rectangle class. However, if the squaretest function above accepts a square object, assert will certainly fail. This violates LSP. The reason is that the rectangle class implies the following assumptions: width and height can be assigned values separately without affecting each other.

Here we need to introduce a design by contract (by contract design) to explain this problem: the essence of LSP is that the derived class must meet the contract followed by the base class. In the above example, the implicit contract of rectangle: Square cannot assign values without affecting each other. From the contract point of view, the derived class must do the following:

1) The preconditions cannot be stronger than the base class.

2) The postcondition cannot be weaker than the base class.

Precondition: A method of the base class can accept all positive numbers, and a derived class overwrites this method and only accepts a number greater than 10000. Then, a caller passing 1000 to this method will fail.

Backend condition example: if a base class method returns an even number, and a derived class overwrites this method to return an odd number, the caller who verifies the return of the base class method fails. In the preceding example, the backend condition is that setting the height does not affect the width, and setting the width does not affect the height. But square obviously cannot do this.

3 Dependency inversion principle (DIP)

Control reversal Principle

Depend upon transferactions. Do not depend on concretions.

If OCP is the target of OO, dip is the main method. Di is a policy that relies on interfaces, abstract functions, or abstract classes, rather than specific functions or classes. This principle is the strength behind the design of COM, CORBA, EJB, and other components.

A procedural Design presents a specific dependency structure. That is, the software is constructed from the bottom up. The upper layer structure is highly dependent on the lower layer module, while the lower layer module is dependent on the lower layer module. This dependency leads to software vulnerabilities. The upper-layer module mainly deals with upper-layer policies and does not care about implementation of lower-layer policies. So why is the upper-layer module directly dependent on the underlying implementation?

The object-oriented design presents a different dependency relationship. The main dependency points to abstraction. The specific implementation of these abstract modules is no longer dependent. On the contrary, these implementation modules also rely on abstraction.

Dependency abstraction. The meaning of dependency inversion is very simple. All dependencies should only depend on abstraction, interfaces, or abstract classes. No dependency should be directed to a specific class. The reason is also very simple: the specific class is easy to change, while the abstract class is much less changed. In addition, abstract classes are placeholders, which indicate that functions can be changed or extended, while abstract classes do not need to be changed.