Re: Circles and ellipses

>> This is the essential problem that the LSP (Liskov Substitution
>> Principle) tries to resolve; or at least identify. Clients of a base
>> class can be confounded by certain derivatives that appear natural.
>
>Thank you! Your explanation was most lucid, concise, and simple enough
 for
>me to follow.
>It was very useful to me. I hope it's similarly useful to others.

Robert's explanation ignored the fact that the setFoci update operation necessarily applies to Ellipse variables -- it does not and cannot apply to Ellipse values.

Since Circle variables do not inherit Ellipse variable assignment, Robert needs to explain why Circle variables should treat any other update operation differently.

In a well-thought language, setFoci does not present any problem. Consider the client of Ellipse that wants to use the operation: The client must specify that the Ellipse argument is passed by value or is passed by reference.

If the client is a non-update operation that specifies one must pass the Ellipse argument by value, the client creates its own ellipse variable to hold the value. Since the ellipse variable can contain any ellipse value -- including a value with two different foci -- the setFoci operation should succeed.

If the client is an update operation that specifies one must pass an ellipse variable by reference, one cannot pass a Circle variable or non-variable to the client. Some languages will create an implicit temporary variable when a value is passed to a reference parameter, but such a variable will be an Ellipse variable.

Only if the language makes no or improper distinction between variable and value will the language allow one to pass a circle variable by reference to an operation expecting an ellipse variable.

Languages such as Java and C++ that rely on named pointer variables create the problem in the first place by ignoring or violating one of the fundamental principles of object orientation: encapsulation. Received on Sun Aug 26 2001 - 20:52:36 CEST