Является ли принцип подстановки Лискова несовместимым с интроспекцией или уткой?

Правильно ли я понимаю, что принцип подстановки Лискова не может соблюдаться в языках, где объекты могут сами себя проверять, как, например, в языках с утиной типизацией?

Например, в Ruby, если класс Bнаследует от класса A, то для каждого объекта xиз A, x.classсобирается вернуться A, но если xэто объект B, x.classне собирается возвращаться A.

Вот заявление LSP:

Пусть д (х) является свойством доказуемо об объектах х типа Т . Тогда д (у) должно быть доказуемо для объектов , у типа S , где S является подтипом T .

Так в Ruby, например,

class T; end
class S < T; end

нарушать LSP в этой форме, о чем свидетельствует свойство q (x) =x.class.name == 'T'

Дополнение. Если ответ «да» (LSP несовместим с интроспекцией), тогда мой другой вопрос: есть ли какая-то измененная «слабая» форма LSP, которая может быть применима для динамического языка, возможно, при некоторых дополнительных условиях и только с особыми типами из свойств .

Обновить. Для справки, вот еще одна формулировка LSP, которую я нашел в Интернете:

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

И другой:

Если S является объявленным подтипом T, объекты типа S должны вести себя так же, как и объекты типа T, если они обрабатываются как объекты типа T.

Последний отмечен:

Обратите внимание, что LSP - это все об ожидаемом поведении объектов. Следовать LSP можно, только если ясно, каково ожидаемое поведение объектов.

Кажется, что это слабее, чем первоначальный, и его можно было бы наблюдать, но я бы хотел, чтобы это было формализовано, в частности объяснил, кто решает, каково ожидаемое поведение.

Тогда является ли LSP свойством не пары классов в языке программирования, а пары классов вместе с заданным набором свойств, удовлетворяемых классом предка? Практически, означает ли это, что для создания подкласса (класса-потомка), уважающего LSP, должны быть известны все возможные варианты использования класса-предка? Согласно LSP, класс предков должен быть заменен любым классом-потомком, верно?

Обновить. Я уже принял ответ, но я хотел бы добавить еще один конкретный пример из Ruby, чтобы проиллюстрировать вопрос. В Ruby каждый класс является модулем в том смысле, что Classкласс является потомком Moduleкласса. Однако:

class C; end
C.is_a?(Module) # => true
C.class # => Class
Class.superclass # => Module

module M; end
M.class # => Module

o = Object.new

o.extend(M) # ok
o.extend(C) # => TypeError: wrong argument type Class (expected Module)

Вот фактический принцип :

Позвольте q(x)быть свойство доказуемо для объектов xтипа T. Тогда q(y)должно быть доказуемо для объектов yтипа, Sгде Sесть подтип T.

И отличное резюме Википедии :

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

И некоторые соответствующие цитаты из бумаги:

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

Спецификация типа включает следующую информацию:
- имя типа;
- описание пространства значений типа;
- Для каждого из методов типа:
--- его имя;
--- его подпись (включая сигнальные исключения);
--- Его поведение с точки зрения предусловий и постусловий.

Итак, к вопросу:

Правильно ли я понимаю, что принцип подстановки Лискова не может соблюдаться в языках, где объекты могут сами себя проверять, как, например, в языках с утиной типизацией?

Нет.

A.classвозвращает класс.
B.classвозвращает класс.

Поскольку вы можете сделать один и тот же вызов для более конкретного типа и получить совместимый результат, LSP удерживает. Проблема в том, что с динамическими языками вы все равно можете называть вещи по результату, ожидая, что они будут там.

Но давайте рассмотрим статически, структурный (утиный) типизированный язык. В этом случае A.classбудет возвращен тип с ограничением, которым он должен быть, Aили подтипом A. Это обеспечивает статическую гарантию того, что любой подтип Aдолжен предоставлять метод T.class, результатом которого является тип, удовлетворяющий этому ограничению.

Это обеспечивает более сильное утверждение о том, что LSP поддерживается в языках, поддерживающих типизацию утиной утилитой, и что любое нарушение LSP в чем-то вроде Ruby происходит в большей степени из-за обычного динамического неправильного использования, чем из-за несовместимости языкового дизайна.

В контексте LSP «свойство» - это то, что можно наблюдать для типа (или объекта). В частности, речь идет о «доказуемой собственности».

Такое «свойство» может существовать foo()методом, который не имеет возвращаемого значения (и следует контракту, установленному в его документации).

Убедитесь, что вы не путаете этот термин с «свойством», так как « classсвойство каждого объекта в Ruby». Такое «свойство» может быть «свойством LSP», но это не то же самое автоматически!

Теперь ответ на ваши вопросы во многом зависит от того, насколько строгое вы определяете «свойство». Если вы говорите , «свойство класса Aявляется то , что .classвозвращает тип объекта», то на Bсамом деле делает имеет это свойство.

Если, однако, вы определяете «свойство» быть « .classвозвращается A», то очевидно , что Bэто не имеет это свойство.

Однако второе определение не очень полезно, поскольку вы, по сути, нашли обходной способ объявления константы.

Насколько я понимаю, в самоанализе нет ничего, что было бы несовместимо с LSP. По сути, пока объект поддерживает те же методы, что и другой, оба должны быть взаимозаменяемыми. То есть, если ваш код ожидает Addressобъект, то это не имеет значения , если это CustomerAddressили WarehouseAddress, до тех пор, как обеспечить (например) getStreetAddress(), getCityName(), getRegion()и getPostalCode(). Вы, конечно, можете создать какой-то тип декоратора, который принимает объект другого типа и использует интроспекцию для предоставления требуемых методов (например, DestinationAddressкласс, который принимает Shipmentобъект и представляет адрес доставки как Address), но это не обязательно и, безусловно, не не препятствует применению LSP.

Просматривая оригинальную статью Барбары Лисков, я нашел, как завершить определение Википедии, чтобы LSP действительно мог быть удовлетворен практически на любом языке.

Прежде всего, слово «доказуемое» важно в определении. Это не объясняется в статье в Википедии, и «ограничения» упоминаются в других местах без ссылки на них.

Вот первая важная цитата из статьи:

Что необходимо, так это более строгое требование, ограничивающее поведение подтипов: свойства, которые можно подтвердить с помощью спецификации. предполагаемого типа объекта, должны сохраняться, даже если объект на самом деле является членом подтипа этого типа ...

И вот второй, объясняющий, что такое спецификация типа :

Спецификация типа включает следующую информацию:

• Название типа;
• Описание пространства значений типа;
• Для каждого из методов типа:
  • Его имя;
  • Его подпись (включая сигнальные исключения);
  • Его поведение с точки зрения предусловий и постусловий.

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

Я считаю, что ответ Теластина наиболее близок к тому, что я искал, потому что «ограничения» были упомянуты явно.

Цитируя статью Википедии о LSP , «заменяемость является принципом объектно-ориентированного программирования». Это принцип и часть дизайна вашей программы. Если вы пишете код, который зависит от x.class == A, то это ваш код нарушает LSP. Обратите внимание, что этот тип испорченного кода также возможен в Java, нет необходимости вводить утку.

Ничто в наборе утки по своей сути не нарушает LSP. Только если вы его неправильно используете, как в вашем примере.

Дополнительная мысль: неужели проверка в явном виде на предметный класс не побеждает цель утиной типизации?