Object-Oriented Analysis, Design and Implementation by Brahma Dathan & Sarnath Ramnath

Author:Brahma Dathan & Sarnath Ramnath
Language: eng
Format: epub, pdf
Publisher: Springer International Publishing, Cham

The getUpperTriangle method does not pose any problem for our Pixel class, since it will always return null. Our troubles start with existing client classes, whose methods have been using the methods of SolidRectangle. Consider the following method in a client class that takes as its input parameter a SolidRectangle object.

This code was written by a client using SolidRectangle, but unaware of Pixel. Since the two corners are set to two distinct points, triangle1 will not be null, and things will be fine. Now if this method is invoked and a reference to a Pixel object is passed as the actual parameter, both the corners will end up being assigned the same point, triangle1 will be null, and we end up with a NullPointerException. Note that there is no simple fix; we may just have to find such code in all the methods of the client classes, and either check for null pointers or check the type of the objects stored in the SolidRectangle references at runtime.

At every step of the this process our choices seemed logical, but we ended up with an undesirable state of affairs. So it is natural to ask: what went wrong? The answer lies in a precise definition the is-a relationship: A pixel object ‘is-a’ SolidRectangle object if and only if the behaviour of Pixel objects conforms to the behaviour of SolidRectangle objects in all situations. The above example shows that the behaviour of getUpperTriangle does not exhibit such conformance when invoked in conjunction with the setCorner methods. One could argue, perhaps, that the method getUpperTriangle is itself poorly designed, but that is really not a choice that we can make now. It is important to keep in mind that we are inheriting from the existing class SolidRectangle and we must accept all its methods. To cast this in terms of the formal statement of the LSP, when we substitute Pixel for SolidRectangle the behaviour of any program should remain unchanged. What we have shown here is that for the program clientMethod, the behaviour changes when such a substitution is made.

The caveat here for the programmer extending a class is therefore that one must check all behaviours of the class being extended, even in situations where a subset relationship exists between the corresponding ‘real-world’ entities.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.