Вопрос подписчика (приводится с сокращениями):
Встретил такой отзыв:
«… ознакомился с книжкой Криса Партриджа “Business Objects: Re-Engineering for Re-Use”. Прекрасное чтение после какого-нибудь руководства по “мейнстримному” объектно-ориентированному проектированию….
Утверждается, что «стандартный» подход к проектированию информационных систем, который автор назвал «сущностным» (entity), несмотря на все заявления его авторов, не позволяет строить сколь-либо сложные модели реальных систем… Это подтверждается примером из статьи Стива Кука и Джона Дениэлса “Object-Oriented Methods and the Great Object Myth”, в котором “миф” о том, что мир состоит из объектов и операций (взаимно-однозначно соответствующих объектам и операциям в модели) разрушается простым примером – когда мы пьем чай, мы не вызываем операцию “пить”, принадлежащую объекту “чашка” – и вообще, представить это простое действие с помощью “объектно-ориентированной” модели очень сложно."
Встал в ступор относительно примера с чашкой. Будет время, прокомментируй, pls»
Идеально! Прекрасно! Впечатляющее! Почему? Потому, что это шикарный повод для разбора мифов об ООП, прям классика жанра!
И как тот самый какой-то автор какого-то руководства по ООП, да еще и в области моделирования таких сложных систем, как бизнес, я не просто готов вывести подписчика из ступора, я готов показать вам, дорогие друзья, что более половины уважаемых гуру, как правило, не знают области, в которой работают. Например, Стив Кук и Джон Дениэлс – либо они сознательно «подтасовывают карты», либо они – обыкновенные профаны. Что плохо, конечно, и в том, и в другом случае. И хотя в вопросе идет речь о программировании, думаю, похожие вопросы могут возникнуть у вас при проектировании с помощью ООП бизнес-моделей.
Разобраться здесь очень просто. Вот что тут происходит:
1. Чашка, имеющая метод «пить» – это диагноз не подхода, а мышления проектировщика.
Если ты в объектной модели вешаешь на чашку метод «пить», значит, ты просто не понимаешь принципов декомпозиции. Это не баг ООП, а баг головы:
– Чашка – это просто носитель состояния (материал, объём, содержимое и пр.), если она в категории smart, то максимум, что она может – сообщить, что в ней, сколько осталось, горячо/холодно и так далее.
– Пить – это действие субъекта, то есть агента (например, человека), который может иметь метод «пить», «есть», «спать», «прыгать». Ну а метод «пить» может иметь свою структуру – «налить(чайник, чашка)», «выпить(чашка, голова)», «разбить(чашка, голова)». В скобках – передаваемые параметры.
В правильной модели метод «пить» должен принадлежать агенту, а не чашке. Потому что чашка не может сама ничего «выпивать», и у неё нет задачи «напитать кого-то». Вешать «пить» на чашку – это как делать у двери метод «зайти», который сам телепортирует человека внутрь.
2. Суть проблемы – косое моделирование, а не недостаток ООП.
Точно так же можно обвинять молоток в том, что с его помощью плохо завязываются шнурки: инструмент надо уметь использовать по назначению. ООП позволяет строить модели любой сложности и адекватности, но всё зависит от правильной декомпозиции и вменяемости проектировщика.
Не ООП плох, плах тот, кто путает пассивные объекты и активные агенты.
В хорошей модели ООП:
– объект обладает набором состояний и простыми операциями с ними.
– действия с объектами – методы агента, который и обладает какой-то целью – необходимостью что-то сделать.
Может ли сущность совмещать в себе и свойства объекта (состояния и методы работы с ними) и свойства агента (методы достижения целей)? Конечно может! Это никак не нарушает постулаты ООП: жажда – пьем, голод – едим...
Более того, именно такая модель создаёт те самые взаимодействия между объектами, что делает множество объектов чем?.. Правильно, системой!
То есть проблема не в парадигме, а в косорукости и скудоумности проектировщика. В хорошем дизайне объект отвечает только за свои собственные дела. Всё остальное – катастрофа на уровне архитектуры, а не парадигмы.