LSP - Liskov Substitution Principle

[juan_gandhi]

Year 1999 Definition: "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."

Original definition looked like this: if for each object o of class S there is an object o1 of class T such that in any program expressed in terms of T o1 can be replaced with o without altering the behavior, then S is a subtype of T.

Which means, you cannot put additional restrictions on a subclass. That is, in programming, a square is not a rectangle - but a parallelepiped is, which is, of course against all our intuition.

How come?

The problem is that in programs objects may change. If they were not, we could safely substitute, in any formula involving a parallelepiped, a parallelepiped P with a cube C, and it will still be valid. If the object does not change, its timeline can be reduced to a point. But for things that change, things change.

Say, we have a parallelepiped that is being deformed; at one moment it can become a cube, but there's no quaranty it will remain one forever. In programming terms, a piece of code may change the length of the parallelepiped, and expect that other dimensions remain the same.

Following this principle, a Timestamp is Java is a subclass of Date, and SortedSet is a subinterface of Set - they add new structure but do not (vaguely speaking) add any new restrictions.

Comments

[109.livejournal.com]

"subclass - superclass" relationship is also called "generalization - specialization" one. which makes alleged problem of "additional restrictions" a non-issue. of course specialized class is "more restrictive"; it can only cover a subset of what superclass can cover. so yes, квадрат - это сабкласс прямоугольника, а прямоугольник - сабкласс четырёхугольника. при чём тут параллелепипед - вообще непонятно, он вообще из другой ветки - из ветки трёхмерных фигур.

[cmm.livejournal.com]

> Which means, you cannot put additional restrictions on a subclass.

this is incorrect.
as long as the subclass plays well with all the protocols with which its parent plays well (i.e. instances of it are freely substitutable for instances of the parent within the relevant context), it can have any additional restrictions it wants.

in general, viewing such problems in the "protocol compatibility" frame of discourse tends to make thinking about them easier.

[furia-krucha.livejournal.com]

Which means, you cannot put additional restrictions on a subclass.
Данные цитаты, вообще-то, говорят о подтипах, а не подклассах. Разумеется, это в общем случае разные иерархии. Квадрат может быть реализован как подкласс прямоугольника, но его подтипом являться не будет.

[ex-chrobin.livejournal.com]

Original definition looked like this: if for each object o of class S there is an object o1 of class T such that in any program expressed in terms of T o1 can be replaced with o without altering the behavior, then S is a subtype of T.

вот это вот can be replaced же только в контравариантных позициях верно, разве нет?