ilovb писал(а):
Это все детали реализации и кишки. То же самое и в 1С. Если ты работаешь с этим напрямую, то это не ООП (в моем понимании). Вот если взаимодействие с такой сущностью идет только через объект или модуль с определенным интерфейсом, который не позволяет нарушить инварианты системы, то это ООП.
Нет, это не детали реализации - это логическая информационная модель, при этом не пассивная, как просто реляционная, а активная, с сообщениями в стиле SOA. Реализация - это уже какая СУБД, как технически что реализуется...
Взаимодействие в плане выполнения бизнес-транзакций идёт через кидание XML-образного (условно называю так) сообщения о необходимости исполнить некую операцию над какой-то сущностью или несколькими сущностями. Кидание идёт просто в единую точку, брокер, - и приходит ответ. А дальше уже правила в брокере определяют, в зависимости от типа сообщения и типа сущности, кто и как это будет исполнять, локально или удалённо и т.п.
Т.е. это - ещё больше ООП, чем ООП.
По сути.
Но данные о состоянии предметной области также являются полностью открытыми для чтения из базы. Для выполнения запросов через язык запросов. Ещё одна особенность автоматизации (как бизнес, так и промышленной), по моему мнению - как правило, структура данных должна быть открытой на чтение. Защищать от чтения и скрывать за интерфейсами нет смысла, если это в границах одной системы (а уже не межсистемные интерфейсы). Иначе это добавляет в громоздкости, но ничего не добавляет ни в надёжности, ни в расширяемости (как только данные становятся персистентными, всё равно об идее безболезненно менять структуру данных приходится забыть. Вся структура персистентных данных, описывающая предметку, должна проектироваться с той же ответственностью, что и интерфейсы).
Цитата:
Не очень понял. Поведение конкретного объекта как-то отделено в системе от всего остального? Если нет, и в системе просто набор общих алгоритмов над СУБД, то это опять-же не ООП в моем понимании.
Отделено. Конкретные виды сущностей и сообщений обслуживают конкретные модули. Там описываются и правила по валидации самих сообщений, и правила в стиле конечных автоматов на возможность выполнения операции над сущностью в текущем состоянии (допусим, сущность "платёж" проходит цепь состояний, описывается КА), и правила прав доступа.
Цитата:
pss Да, и наследование я к ООП не отношу. Это бред, выдуманный Страуструпом etc
В итоге и получается, что нет смысла тащить чисто-программистский, пропитанный языковыми артефактами всяких разных языков, термин ООП в сферу, которая уже называется "системное моделирование", "системная инженерия" (это ведь устоявшиеся, стандартизированные названия, профессии даже).
Т.е. стандартная общепринятая нагрузка термина ООП: "Для Атоса (программирования, организации кода) это слишком много, а для графа де Ла Фер (прикладной автоматизации, системной инженерии) - слишком мало".
Изжил себя термин в широком смысле. Ну вот вершины его развития: RUP - rational unified process - "мертвечина" же! Domain Driven Design Эрика Эванса - мощый целостный подход, да. Мышление верное. А потом в рамках отображения предметки на джавовские классы, все эти Object-Relation-Mapping-и и т.п. становится весьма тесно и не-очень-уклюже. И следующий шаг, который просится от его методологии - это сохраняя стиль мышления, вылезти за эти языковые рамки.