LSP - Liskov Substitution Principle
Apr. 10th, 2007 02:22 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
juan_gandhiYear 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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-04-11 06:11 pm (UTC)а в рамках ООД выбора особенного нет.
общий родитель взялся от того, что у них обоих по 4 стороны и все углы прямые.
no subject
Date: 2007-04-11 09:43 pm (UTC)почему от этого должен браться общий родитель? кто нам это сказал? общий родитель бывает, когда у двух объектов есть методы, которые мы готовы считать попарно «одинаковыми» (в том смысле, что объекты «одинаково» реагируют на «одинаковые» вызовы). пока неясно, как из одинакового количества углов следует одинаковость методов.
no subject
Date: 2007-04-11 09:51 pm (UTC)пример: в обоих классах есть совершенно одинаковый кусок некой сложной логики. сам по себе этот кусок не экспозится наружу в виду публичного метода. то, что экспозится - отличается. тем не менее, вполне может иметь смысл выделить этот кусок и запихнуть в родителя в виде protected метода, который будет вызывать ребёнко-специфичные вещи, определённые в родителе как абстрактные. это, на самом деле, и есть основная причина появления на свет родителей, и иерархий вообще, а не "у двух объектов есть методы, которые мы готовы считать попарно одинаковыми".
no subject
Date: 2007-04-11 10:16 pm (UTC)no subject
Date: 2007-04-12 01:19 am (UTC)вспомним, что изначальная проблема, таковой на самом деле не являющаяся, возникла при рассмотрении метода setSides(x, y). имплементации, то бишь.