Здравствуйте, craft-brother, Вы писали:
CB>Здесь и зарыто главное ограничение ООП, которое делает наши программы сложнее, чем они могли бы быть. ... "The Liskov Substitution Principle"
Принцип Лискова — вообще бомба. Он говорит нам о том, что:
1. В программировании хвост, виляющий собакой — обычная ситуация. Здесь хвост — это дизайн подсистемы/сервиса, а собака — это дизайн системы.
2. Пока ты в совершенстве не освоил телепатию и не научился путешествовать туда-сюда по времени, ты не можешь считаться хорошим программистом-инструментальщиком. Попытка заменить эти базовые навыки банальной интуицией — всего лишь полумера.
CB>Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.
Это, конечно, позволит нам забороть стрёмный принцип Лискова. Но трудности на этом не кончаются. Поняв, что будет создан человек и выяснив, что он собирается делать с этими объектами (носить, поджигать, пилить, растворять в кислоте, грызть, прибивать, нюхать, складывать в штабеля, красить, поклоняться, выращивать, продавать и т.д.), мы начинаем медленно сходить с ума.
Базовая операция, на которой держится весь ООД — это операция обобщения. Если мы не можем нормально обобщить (выделить базовый класс), то большую половину всех вкусностей ООП мы не получаем. С одной стороны, живое дерево и мёртвый камень — принципиально разные объекты, но если судить по тому, что с ними можно делать (необходимый набор интерфейсов), то это почти одно и то же. Как выкручиваться? Известно как:
1. Создать оччччччччень толстый базовый класс CObject, в который напихать уйму свойств и виртуальных методов. А потом, понять, что жизнь наша от этого не облегчилась. И удивляться, почему всё так страшно тормозит и почему оперативка забилась таблицами виртуальных методов.
2. Применить какой-нибудь выверт типа множественного наследования или интерфейсного подхода. То есть вместо того, чтобы пройти по скользкой, опасной и длинной дороге обобщения один раз, мы будем ходить по множеству коротких, но от этого не менее скользких и опасных.
Кроме того, есть ещё одна тонкая проблема, которая мешает легко и радостно применять ООД. Это проблема выделения объектов из предметной области. Что считать объектом? Деревяшку? Камень? ОК. А деревяшку, приклеенную к другой деревяшке будем считать объектом? Куча камней — это объект? Куча мусора, в которой есть и камни, и деревяшки — это объект? Подгнивший краешек доски — это отдельный объект или как? Нарисованный камень, абстрактный камень, "что-то непонятное, торчащее из земли"???
Философская подоплёка этой проблемы заключается в том, что в реальном мире не существует объектов. То, что мы воспринимаем как "объекты", носим с места на место, поджигаем, пилим, растворяем в кислоте, грызём и т.п. никакой объектной сущностью не обладает. Деление мира на объекты — это особенности вычислительной модели, на которой основана работа устройства, расположенного у нас между ушами. Мы произвольно можем выделять объекты так, как нам это удобно. Логика — нечёткая. Сегодня я любуюсь камнем, а завтра — фотографией этого камня, и для меня это один и тот же объект. Компутер так не может. У него чёткая логика. У него однозначные интерпретации (а все неоднозначности — это либо ошибка программы, либо ошибка пользователя, но в любом случае мы с неоднозначностями предпочитаем бороться).
Вот и получается, что пока программа работает с простыми (желательно искусственными) сущностями типа элементов оконного интерфейса, ООП полезен и показывает себя с хорошей стороны. Как только сложность возрастает, ООП становится обузой.
Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем.
