Презентация1

1.

Принцип подстановки
Барбары Лисков

2.

Принцип подстановки Лисков(англ. Liskov Substitution Principle,
LSP) – принцип организации подтипов в объектно-ориентированном
программировании, предложенный Барбарой Лисков в 1987 году
Гласит:
Если q(x) является свойством, верным относительно объектов x
некоторого типа T, тогда q(y) также должно быть верным для
объектов y типа S, где S является подтипом типа S.

3.

Это принцип, согласно которому клиентский код должен работать с
объектом класса-наследника точно также, как и с объектом базового
класса.
Класс-наследник
должен
расширять
функционал
родительского класса, а не сужать его.

4.

Таким образом, клиентский код – любой код приложения, имеющий
межклассовые отношения (зависимость, агрегация, композиция и т.д.) с
супер-классом.

5.

А что случится, если в наш клиентский метод передать в качестве
параметра объект типа ChildClass?
Чтобы был соблюден принцип подстановки, случиться ничего не
должно. Клиентский код должен спокойно «проглотить» объект классапотомка вместо объекта супер-класса и не заметить разницы, не
сломаться. Должна отсутствовать необходимость даже самым
малейшим образом дорабатывать клиентский код.

6.

Промежуточный итог
Принцип подстановки заключается в подстановке
объекта-класса потомка в клиентский код вместо
объекта базового класса, при этом клиентский код
остаётся неизменным и работоспособным.

7.

Проверка правильности наследования
Чтобы понять, правильно ли было выполнено наследование в
целом и переопределение в частности, необходимо осуществить
ряд проверок.
Введем для удобства иерархию произвольных типов и
произвольных исключений (Exceptions):
Слева – иерархия типов, справа – исключений. Каждый нижестоящий
класс является подтипом вышестоящего

8.

9.

Приступим к проверкам. Более абстрактный класс, находящийся выше в
иерархии наследования, мы будем считать более широким, а более
конкретный, находящийся ниже, соответственно, узким. Пойдём слева
направо по переопределенному методу в классе-потомке и сравним его с
исходным в супер-классе:
1. Модификатор доступа. Может быть такой же или шире. Проверяется
компилятором. Смотрим в код: отношение public/protected
2. Возвращаемое значение. Такое же или уже. Проверяется компилятором. В
примере: SubType/MiddleType.
3. Параметры метода. Такие же или шире. В примере: MiddleType/MiddleType
4. Выбрасываемое исключение. Такое же или уже. Проверяется
компилятором. В примере: SubException/MiddleException.
5. Предусловия. Такие же или мягче. Не проверяются компилятором.
6. Пост-условия. Такие же или жёстче. Не проверяется компилятором.
Ситуация похожа на ту, что была в предыдущем пункте, только наоборот.

10.

7. Инварианты класса. Класс-потомок не должен изменять инварианты своего
родителя. Не проверяется компилятором.
8. Значения приватных полей родительского класса. Не должны изменяться
классом-наследником. Не проверяется компилятором.
Если класс-потомок соответствует приведённым выше требованиям, то
он не несёт опасности для клиентского кода и можно сказать, что
принцип подстановки Барбары Лисков соблюдён.

11.

Чтобы легче было запомнить весь материал, обратимся к
иллюстрации:
На картинке мы видим наш переопределенный метод, который обходили.
Направление обхода обозначено очень красной и очень изогнутой стрелкой.
Проследим закономерность: Шире-Уже-Шире-Уже-Мягче(Шире)-Жестче(Уже).
Сожмем это до ШУШУШУ и добавим остальное: И (инварианты) приватные
поля. В итоге получаем фразу-запоминалку: «Шушушу И приватные поля».
Теперь, даже если вы ничего не поняли в проверках, вы все равно их
перечислите, просто воспроизведя в памяти синтаксис объявления метода в
Java и эту заветную фразу. И вряд ли забудете, даже если очень захотите.