From the "Liskov replacement principle" and "Refused Bequest", we can see why the square cannot inherit the rectangle"

Suppose our current requirement is to implement a rectangle, So we wrote the code like this:

Class Rectangle
{
Protected double width;
Protected double height;

Public double Width
{
Set {this. width = value ;}
Get {return this. width ;}
}

Public double Height
{
Set {this. height = value ;}
Get {return this. height ;}
}

Public double Area // calculates the rectangular Area.
{
Get {return this. width * this. height ;}
}
}

This program runs well and is installed to multiple clients. But now the demand has increased, and the Client needs a cube Square. According to the point of view of Plane Geometry, a Square is a special Rectangle with the same length and width, that is, the Square IS-A Rectangle, so we let Square inherit the Rectangle class. (PS: After Square inherits the Rectangle, it also has the corresponding width and height fields. Given that the length and width of Square are equal, it only needs one of the two fields, this wastes memory resources (if many Square object instances are defined in the program ).)

Class Square: Rectangle
{
Public new double Width
{
Set {base. Height = base. Width = value ;}
Get {return base. Width ;}
}/** // * Because the parent class Rectangle is not designed to be inherited by Square in the future, the width and height fields in the parent class are set to private, in the subclass Square, you can only call the attributes of the parent class to set/get. */

Public new double Height
{
Set {base. Width = base. Height = value ;}
Get {return base. Height ;}
}
}

This Code seems to be running well. No matter what operations we perform on Square and Rectangle objects, it is consistent with the Square and Rectangle in mathematics. It seems that the design is self-compatible and correct, but a self-compatible design may not be compatible with all user programs. For example, before defining Square, we perform the following unit tests on angle:

Void TestRectangle (Rectangle r)
{
R. Weight = 10;
R. Height = 20;
Assert. AreEqual (10, r. Weight );
Assert. AreEqual (200, r. Area );
}
Rectangle r = new Rectanglt ();
TestRectangle (r );

This test code runs OK, but now we have the Square class, Square IS-A Rectangle, what if we pass in a Square object?

Square s = new Square ();
TestRectangle (s );

Now both Assert tests fail... in this case, Square cannot replace Rectangle in some cases. It is an unreasonable design to let Square inherit Rectangle, which violates the Liskov replacement principle (LSP ).

(Form Agile Software Development: Principles, models, and practices, hereinafter referred to as PPP) LSP gives us a very important conclusion: a model, if you look at it in isolation, it is not really effective. The validity of the model can only be expressed through its customer program. For example, to view Rectangle and Squre in an isolated manner, they are self-compatible and valid. However, from the perspective of the customer program TestRectangle (Rectangle r) that makes reasonable assumptions on the base class Rectangle, this model is faulty.When considering whether a specific design was just at the time, we could not look at the solution in full isolation, but we had to examine it based on the reasonable assumptions made by the users of the design.

At present, there are also some technologies that support us to clarify reasonable assumptions, such as Test-Driven Development (TDD) and Design by Contract (DBC ). But who knows what reasonable assumptions the design users will make? Most of these assumptions are unpredictable. If we predict all the assumptions, the system we design may also be full of unnecessary complexity. The Recommended Practice in the book PPP is to predict only the most obvious violations of LSP, and to postpone the prediction of all other assumptions until the relevant vulnerability Smell (Bad Smell) occurs) to process them. I think this sentence is not straightforward enough. In Martin Fowler's Refactoring book, the description of "Refused Bequest" is more detailed: the Child class inherits the methods and data of the parent class, however, subclasses only need part of the parent class Methods or data, rather than all methods and data. In this case, it means that there is a problem in our inheritance system. For example, in the preceding Rectangle and Square, Square itself has the same length and width, and edge lengths are used to represent edges in the ry. In the Rectangle and width, Square has already Refused the Bequest of Rectangle, it is an unreasonable design to inherit Rectangle from Square.

Now back to the basic concept of object-oriented, subclass inherits the parent class to express a IS-A relationship, which is considered to be one of the basic technologies of Object-Oriented Analysis (OOA. But the square is indeed a rectangle, do they do not have a IS-A relationship between them? In this regard, the book Java and patterns explains that when we design an inheritance system,Subclass should be an alternative parent class, Is an alternative relationship, not just the relationship of IS-A; and the interpretation of PPP book is: From the Perspective of behavior, Square is not Rectangle, the behavior of objects is a real concern of the software. LSP clearly points out that,In the case of a IS-A relationship in OODThe customer program can make reasonable assumptions about the behavior mode. In fact, they both express the same meaning.

 

Refer:
Agile Software Development: Principles, models and practices
Java and Mode
Reconstruction