Привет!

У меня тут мега инсайт. Я лет 8 назад разочаровался в ООП и с тех пор говорил, что это облажавшая хрень, которая, на самом деле не захватила мир и миром всё ещё правит ПП.

При этом я верю в ООД. Когда-нибудь я напишу пост, в чём для меня разница, но если вкратце, для меня ООП - это классы, а ООД - подсистемы

Поэтому я время от времени читаю книги по ООП/ООД и сейчас читаю Designing object-oriented software.

Я там сразу обратил внимание на примеры - банкомат и редактор документов.
Тут у меня появилась идея, что может ООП не в целом облажалось, а просто (внезапно) не является серебренной пулей и не стрельнуло в моей отрасли разработки ПО - информационных системах? Пошёл смотреть другие примеры.

Applying UML and Patterns - автоматизация кассы

Object Oriented Software Construction - система резирвации авиа билетов с фокусом на UI, undo в интерактивной систему

Object-Oriented Software Engineering: A Use Case Driven Approach - система управления складом с фокусом на UI, телеком

Object Design: Roles, Responsibilities, and Collaborations - система общения парализованных людей, по средствам моргания глазами

Object-Oriented Analysis and Design with Applications - спутниковая навигация, система управления трафиком, криптоанализ, наблюдение за погодой, система управления отпусками (вот кажись единственный похожий пример)

Working with objects: The OOram Software Engineering Method - "business information system" но на беглый взгляд, фокус всё равно на UI, система реального времени, фреймворк

The Object-Oriented Thought Process - игра в 21

Head First Object-Oriented Analysis and Design - информационная система магазина гитар, но на списках:(

Львиная доля примеров - сильно отличаются от того, с чем работаю я. Там либо высокоинтерактивная система, либо активная работа с оборудованием, либо UI.

Так что, наверное, для ООП есть место в мире, просто не моём:)

А для разработки информационных систем я советую:
1) следовать ООД при декомпозиции системы на подсистемы - каждая подсистема должна инкапсулировать в себе какую-то часть состояния всей системы, и предоставлять публичное АПИ для его изменения
2) следовать функциональной архитектуре в реализации отдельных подсистем - разбивать код на чистое ядро с бизнес-правилами, и императивную оболочку с вводом- выводом
3) максимум кода тащить в чистое ядро и делать это ядро понастоящему чистым - с неизменяемыми структурами данных и функциями без эффектов
4) а императивную оболочку делать максимально тонкой, прямолинейной и простой

#oop@ergonomic_code #books@ergonomic_code #ergo_approach@ergonomic_code