Re: OO Concept: Liskov Substitution Principle

On Fri, 30 May 2008, howa wrote:

Just read an article talking about the LSP in term of OO design:
http://www.objectmentor.com/resources/articles/lsp.pdf

Okay, firstly that article is crap.

The article said Rectangle class should not be a superclass of Square
class.

Okay, so how you would design the Rectangle & Square class?

I'd start by going back in time and giving Barbara Liskov a sound kicking.

I mean, she's bang on about how subclasses must be able to stand in for superclasses and fulfil the same contracts. That's a fundamental principle of type theory. More than type theory - type law! But her classic definition is mind-numbingly bad:

"What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o2 is substituted for o1 then S is a subtype of T."

If the instance being of a different class doesn't change the behaviour, then there's no point in having that class, is there? What she meant was that it should obey the same contracts, but she didn't say that, and ludicrous quantities of arguments about the matter filled up most of the 1990s. She later stated it much more clearly:

"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T."

Which, as long as you understand 'property' to mean 'contractually defined property', is bang on.

A more general, and to my mind useful, way of thinking about substitutability is in terms of covariance and contravariance. I don't have time to explain this right now, so have a read (this is not a great article, but it's a start):

http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29

I note that Jon Postel actually beat Barbara Liskov, and the category theorists, to the punch with his famous law about protocols:

http://en.wikipedia.org/wiki/Robustness_Principle

Which is, when you think about it, exactly the requirement that is incumbent upon subtypes.

Anyway, to answer your question, i'd descend Square from Rectangle, and make them both immutable.

If you need to be able to resize Rectangles, i'd have a method like:

public Rectangle setWidth(int w)

Which returns a new rectangle. Square implements this by returning a Rectangle, and all is well.

public class Rectangle {
private double w ;
private double h ;
public Rectangle(double w, double h) { ... }
public Rectangle scale(double scaleFactor) {
return new Rectangle((w * scaleFactor), (h * scaleFactor)) ;
}
public Rectangle setWidth(double w) {
return new Rectangle(w, this.h) ;
}
}

public class Square extends Rectangle {
private double s ;
public Square(double s) { ... }
public Rectangle scale(double scaleFactor) {
return new Square(s * scaleFactor) ;
}
public Rectangle setWidth(double w) {
return new Rectangle(w, this.s) ;
}
}

Dead simple.

tom

--
A military-industrial illusion of democracy
.

Relevant Pages

  • Re: Class hierarchy
    ... > The discendents arre th classes Trapezoid, Parallelogram, Rectangle, ... which differ only in their constructors. ... class Square: public Rectangle ...
    (comp.lang.cpp)
  • Re: Why is OO Popular?
    ... Ellipses are circles is horribly wrong and squares are rectangles is ... Circles are ellipses breaks LSP ... > rectangle can be changed independently ... square value in a rectangle variable or a square value in a square ...
    (comp.object)
  • Re: Agile Ecosystems Vs (Rational) Unified Process
    ... > conflict between Rectangle and Square, and not one line of code ... and practice on the other are seen as mostly independent and separate ... Google Home - Advertising Programs - Business Solutions - About Google ...
    (comp.object)
  • Re: SubTyping versus SubClassing
    ... small subset of ones used in mathematics. ... >> which you'd better have a square for each rectangle, ... Operations defined on the types are that theorems we have to prove ...
    (comp.object)
  • Re: delegation vs. inheritance
    ... the debate centered around deriving Rectangle behaviors from Square behaviors. ... The real problem was that Square was defined with a sideLength knowledge attribute while Rectangle was defined with majorSideLength and minorSideLength -- apples & oranges. ... So if one defined sideLengthN for Square, then Rectangle could be a subclass without any LSP inconsistency in the knowledge attributes. ...
    (comp.object)