Ood principle of the Richter scale replacement (LSP)

The Richter replacement principle (Liskov substitutiion PRINCIPLE,LSP) is called the cornerstone of inheritance reuse, and it is presented even earlier than the OCP. Unfortunately, due to the different understanding of this principle, after many translations, the LSP has become one of the most controversial topics in ood design principles.

In fact, at the OOPSLA conference in 1987, Ms. Liskov of the MIT Computer Science Lab published the classic article Data abstraction and Hierarchy, which proposed the Liskov substitution principle named after her (the Liskov Substitution Principle), hereinafter referred to as LSP. This principle explains when to use inheritance, when to use it, and why. A year later this article was published in ACM's Sigplan Notices magazine, which has far-reaching implications. Liskov writes in this article:

A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype was one whose objects provide all the behavior of objects of another type (the supertype) p LUs something extra. What's wanted here's something like the following substitution property:if for each object O1 of type S there are an obj ECT O2 of type T such that for all Programs p defined in terms of T, the behavior of P was unchanged when O1 was substituted For O2 then S is a subtype of T.

This means: "The type hierarchy is composed of subtypes and supertype (that is, the parent class), and intuition tells us that the meaning of the subtype is that the object of that type provides all the behavioral functions of an object of another type (super-type) and is expanded. The following substitution properties are required: For each Type S object O1, there is an object O2 of type T, so that in all program p written for T, after replacing O2 with O1, the behavior function of program P is not changed, then S is the subtype of T. This is the initial meaning of the LSP.

Robert Martin, a well-known technical writer, wrote an article titled "The Liskov Substitution Principle" in 1996 for the C + + Reporter, which specializes in LSP. In Martin's article, he gave the LSP an explanation:

Functions that use pointers or references to base classes must is able to use objects of derived classes without knowing I T.

This means: "Using pointers to base classes or referenced functions, you must be able to use them without knowing the specific derived class object types." "In 2002, Martin was further simplified in his book" Agile Software Development Principles Patterns and practices ":

Subtypes must is substitutable for their base types. Subclasses must be able to replace them with their parent classes.

It is precisely because of this many versions of the existence of the addition of translation, reporting and so on, resulting in a variety of LSP understanding (not delve into it). As I understand it, the above Liskov expression is not difficult to understand, though it is a mouthful. In addition to Martin's explanation, the LSP principle is clear.

LSP is actually in the process of building the inheritance structure of the class need to follow the basic principles, when to use, when not to use, to avoid the abuse of inheritance. LSP and OCP are associated, and can be said to be the basic guarantee of the OCP. Imagine if a function used a pointer or reference to a base class, but the design of the class violates the LSP principle, then this function must know all the derived classes of that base class. This function clearly violates the open-closed principle OCP, because once the subclass of the base class is newly constructed, this function needs to be modified.

I also say that the classic "square is not a rectangle" problem. In the world of mathematics, a square is, of course, a rectangle. Using OO data, the relationship between the square and the rectangle is is-a-a relationship that is exactly the basis for determining the inheritance relationship in the OO beginner's tutorial. So, of course, square classes should inherit the rectangle class rectangle:

public class Rectangle
... {
private long width;
private long height;
public void SetWidth (long width) ... {
This.width=width;
}
public void SetHeight (long height) ... {
This.height=height;
}
Public long getwidth () ... {
return width;
}
Public long getheight () ... {
return height;
}

} ;

public class Square:rectangle
... {
public void SetWidth (long width) ... {
This.width=width;
This.height=width;
}
public void SetHeight (long height) ... {
This.width=width;
This.height=width;
}
} ;

Suppose there is such a function: Public Rectangle increaseheight (Rectangle R)
... {
while (R.getheight () <r.getwidth ()))
... {
R.setheight (R.getheight () + +)
}

return R;
}

If passed to Increaseheight is a rectangle (a different length and width) of the object, no problem, if you pass a square object ... Everyone knows what the outcome will be. The reason for this problem is that the design of the inheritance structure violates the LSP principle: The square class is different from the processing and rectangle logic of height and weight, rectangle changes widtht and height individually, Square must also change the width and height. Therefore, the inheritance between square and rectangle is not tenable. You can add an abstract class quadrangle, define a common method of quadrilateral, and both square and rectangle inherit these methods from quadrangle, while adding their own unique methods:

In fact, not only this "classic" problem reflects the real world concept and OO concept of the difference, many situations need to be ood in the time to think carefully. It is possible to implement the OCP only if it complies with the LSP rules. The following articles are available as a practical experience:

1. Inherit from the abstract class and do not inherit from the entity class. Because entity classes have methods that are related to specific entities, these methods may not be useful in subclasses.

2. Use a contractual programming approach. DBC (Design by contract) regards the relationship between the class and its customers as a formal agreement that clarifies the rights and obligations of the parties. In the parent class, you define the functions that subclasses need to implement, and subclasses can only implement these functions.

3. The behavior capabilities of all derived classes must be consistent with what the client program expects from its base class. The above example is a violation of this article. In fact, this is the basic requirement of OO in inheriting and rewriting.