Принцип подстановки Лискова и направленность исходного утверждения - PullRequest
1 голос
/ 05 сентября 2010

Сегодня вечером в вики Ward'а я натолкнулся на первоначальное утверждение Принципа подстановки Лискова:

Здесь нужно что-то вроде следующего свойства подстановки: Если для каждого объекта o1 типа S естьобъект o2 типа T такой, что для всех программ P, определенных в терминах T, поведение P остается неизменным, когда o1 заменяется на o2, тогда S является подтипом T. "- Барбара Лисков, Абстракция данных и иерархия, Замечания SIGPLAN, 23,5 (май 1988 г.).

Я всегда был дерьмом в разборе логики предикатов (хотя я впервые потерпел неудачу с Calc IV), так что пока я вроде понимаю, как это переводитсяto:

Функции, использующие указатели или ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная этого.

то, чего я не понимаю, - это почемусвойство, которое описывает Лисков, подразумевает, что S является подтипом T, а не наоборот.

Может быть, я просто еще недостаточно знаю об ООП,но почему утверждение Лискова допускает только возможность S -> T, а не T -> S?

Ответы [ 3 ]

0 голосов
/ 05 сентября 2010

Как указывает sepp2k, есть несколько представлений, объясняющих это в другом посте.Вот мои два цента об этом.Мне нравится смотреть на это так

Если для каждого объекта o1 типа TallPerson существует объект o2 типа Person, такой, что для всех программ P, определенных в терминах Person, поведение P остается неизменным, когда o1заменяется на o2, тогда TallPerson является подтипом Person.(замена S на TallPerson и T на Person)

Как правило, у нас есть объекты, у которых некоторый базовый класс обладает большей функциональностью, поскольку он расширен.Однако с большей функциональностью мы специализируемся на этом и сокращаем область, в которой они могут использоваться, таким образом становясь подтипами своего базового класса (более широкий тип).

0 голосов
/ 05 сентября 2010

Производный класс наследует открытый интерфейс своего базового класса и, как ожидается, будет либо использовать унаследованную реализацию, либо предоставлять реализацию, которая ведет себя аналогично (например, метод Count() должен возвращать количество элементов независимо от того, как эти элементы хранятся .)

Базовый класс не обязательно будет иметь интерфейс любого (не говоря уже о всех ) его производных классов, поэтому не имеет смысла ожидать произвольную ссылку на базовый класс для замены указанного производного класса. Даже если кажется, что требуется только подмножество интерфейса, поддерживаемого интерфейсом базового класса, это может быть не так (например, может случиться так, что упоминается метод теневого копирования в конкретном производном классе).

0 голосов
/ 05 сентября 2010

гипотетический набор программ P (в терминах T) не определен в терминах S, и поэтому он мало говорит о S. С другой стороны, мы говорим, что S работает так же, как и T в этот набор программ P, и поэтому мы можем сделать выводы о S и его связи с T.

Один из способов думать об этом состоит в том, что P требует определенных свойств T. S случается, чтобы удовлетворить эти свойства. Возможно, вы могли бы даже сказать, что «каждый o1 в S также в T». Этот вывод используется для определения слова подтип.

...