Я развенчал SOLID и заменил шаблоны проектирования одной архитектурой, поэтому я предоставлю вам контраргумент.
Суть Лискова заключается в следующем:
Является ли отвертка отверткой, когда вы переопределяете метод Rotate () и полностью заменяете поведение, нарушая способность объекта вращаться? (Это меняет то, что вертикально интегрировано.)
Является ли телефон телефоном больше, когда вы переопределяете его метод 5 () и отображаете число 5 в GUI при вызове базового метода ? (Это создает вариант продукта с помощью вертикальной интеграции или вертикального роста.)
Является ли телефон больше телефоном, когда вы переопределяете метод Ring (), чтобы добавить функцию голосовой почты после 3 кольца? (Опять же, вертикальная интеграция.)
Другими словами, Лисков - это ограничение, которое гарантирует, что ваш класс все еще находится в том же «семействе машинных продуктов». OOP приверженцы считают, что это согласуется с их концептуализацией класса: физически отдельной машины, которая имеет один или несколько методов и контролирует доступ к внутренним данным. Лискову необходима целостность парадигмы OOP. Без Лискова концептуализация OOP развалится.
Но здесь Лисков и OOP ошибаются.
Производственные процессы не централизуют инструкции процесса - известные как маршрутизация источника - для семейства продуктов, как если бы процесс содержал ветви, которые интерпретируют пользовательские настройки как различные операции. Вместо этого каждый вариант продукта имеет свою собственную копию полного набора инструкций, и каждая операция не содержит разветвлений. Любое внутреннее перенаправление продукта, например дефекты, будет немедленно задокументировано в активном маршрутном документе. Не все производители придерживаются этого стандарта, но это стандарт.
Harvard Business Review объясняет, что процессы, которые централизуют операции, по сути, централизуют требования - процесс - это просто последовательность операций, запрошенных пользователем. Поэтому создание подклассов для расширения существующего метода создает то, что я называю сложностью централизации , и уничтожает документацию о том, кто владеет каждым процессом. Это необратимо. http://www.powersemantics.com/p.html
Правильный способ создания производного процесса состоит в том, чтобы полностью скопировать исходные инструкции, задокументировать, какие пользователи владеют им, а затем разрешить только этим пользователям настроить его с течением времени. Однако нет правильного способа создать производную машину , потому что «пользователи телефона базового класса» обязательно владеют кнопкой 5 (), а «пользователи телефона подкласса» владеют вашей более красивой моделью. Означает ли это, что пользователи базового класса имеют право принимать решения о новых функциях, которые получают все пользователи подкласса? Не существует правильного способа централизовать требования пользователей, есть только способы достижения сложности. Барбара была не права. Здесь нет «подтипов» классов. Никто. Нуль. Шиш. Схемы произвольной категоризации не являются основанием для централизации структуры машины. Обратитесь к подлинным академическим c принципам механического проектирования, если вы хотите научиться настоящему инженерному делу, а не догме.