Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 Рассмотрим пример. Допустим, мы решили написать свой собственный логгер (объект, который записывает в журнал произвольные сообщения).

3 Логгер позволяет записывать сообщения с разным уровнем важности, начиная отdebugи доemergency. Сигнатура метода log() устроена таким образом, что первым параметром всегда передается уровень сообщения, а вторым сообщение. Само сообщение - это строка произвольного формата, а уровнем может быть один из 8 вариантов.

4 Уровень важности позволяет менять режимы вывода. Например, в разработке выводятся все сообщения, включая отладочные, а в продакшене выводятся только серьезные ошибки, чтобы не загрязнять журналы

5 Предположим, что нам это не понравилось, и мы решили изменить сигнатуру так, чтобы уровень передавался вторым параметром. Это позволит задать нам значение по умолчанию для того уровня, который чаще всего встречается в приложении. Для этого создадим класс-наследникMyLogger.

6 Что не так с этим кодом? Подобное изменение сигнатуры делает невозможным полиморфизм. Эти классы несовместимы между собой.

7 Этот код отработает неверно (или завершится с ошибкой), так как объект database будет использовать логгер в соответствии с требованиями Logger, что противоречит тому как работает MyLogger.

8 В 1987 году Барбара Лисков сформулировала принцип подстановки (Liskov Substitution Principle - LSP), который позволяет правильно строить иерархии типов, если ему следовать:

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

10 </blockquote>Звучит математично. Многие разработчики пытались переформулировать это правило так, чтобы оно было интуитивно понятным. Самая простая формулировка звучит так:

11 <blockquote>Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.

12 </blockquote>В примере выше функция setLogger(logger) ожидает на вход объект, соответствующий сигнатуре методов Logger, а мы передали ей MyLogger, который не следует первоначальной сигнатуре. Согласно принципу, код должен продолжать работать как ни в чем не бывало, но этого не происходит из-за нарушения интерфейса.

13 JavaScript - язык с утиной типизацией, поэтому понятие типа не выражено явно. Типом, в данном случае, называют интерфейсы. Они есть в таких языках как PHP/Java/C++/TypeScript. В JavaScript тип существует на логическом уровне, в нашей голове. Считайте, что тип - это сигнатура методов конкретного класса. Если у двух классов совпадают методы (по имени и сигнатуре), то они полиморфны по этому методу или набору методов.

14 Для любознательных. Почему вообще понадобился этот принцип? Почему бы не поручить эту работу языку? К сожалению, технически невозможно убедиться в соблюдении принципа Лисков. Поэтому его выполнение ложится на плечи разработчиков.

15 <h2>Правила проектирования иерархий типов</h2>

16 Существует несколько правил, которые надо учитывать при работе с типами:

17 <ul><li>Предусловия не могут быть усилены в подклассе</li>

18 <li>Постусловия не могут быть ослаблены в подклассе</li>

19 <li>Исторические ограничения</li>

20 </ul>Предусловия - это ограничения на входные данные, а постусловия - на выходные. Причем в силу ограничений систем типов, многие из таких условий невозможно описать на уровне сигнатуры. Их либо придется описывать просто текстом, либо добавлять проверки в код (<a>проектирование по контракту</a>).

21 Например, в нашем логгере предусловием является то, что метод log() первым параметром принимает один из 8 уровней сообщений. Принцип Лисков утверждает, что мы не можем создать класс, реализующий этот интерфейс (логически), который может обрабатывать меньшее число уровней. Это и называется усилением предусловий, то есть требования становятся жестче. Вместо 8 уровней, например 5. Попытка использовать объект такого класса, закончится ошибкой, когда какая-то из систем попробует передать ему уровень, который не поддерживается. Причем не важно, приведет это к ошибке (исключению) или логгер молча проглотит это сообщение не записав его в журнал. Главное, что поведение стало отличаться.

22 Встречаются ситуации, когда разработчики не видя причину такого поведения, начинают лечить следствия. В местах, где используются подобные объекты, добавляются проверки на типы. А это убивает полиморфизм.

23 С постусловиями ситуация аналогичная, но наоборот. Допустимо, если метод возвращает урезанный набор значений, так как этот набор все равно укладывается в требования виртуального интерфейса. А вот расширять возврат нельзя, так как появляются значения, которые не были предусмотрены интерфейсом. Это относится и к исключениям.

24 И последнее, исторические ограничения. Подтипы (в случае JS - классы-наследники) не могут добавлять новые методы для изменения (мутации) данных базового типа (в случае JS-класса). Способы изменения свойств, определенных в базовом типе, определяются этим типом.