Re: OO Concept: Liskov Substitution Principle
- From: Tom Anderson <twic@xxxxxxxxxxxxxxx>
- Date: Fri, 30 May 2008 17:36:10 +0100
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
.
- References:
- OO Concept: Liskov Substitution Principle
- From: howa
- OO Concept: Liskov Substitution Principle
- Prev by Date: Re: Newbie Eclipse question: Exported jar file does nothing upon execution
- Next by Date: Re: OO Concept: Liskov Substitution Principle
- Previous by thread: Re: OO Concept: Liskov Substitution Principle
- Next by thread: Re: OO Concept: Liskov Substitution Principle
- Index(es):
Relevant Pages
|
