Являются ли все успешные и легко обслуживаемые программные приложения строго объектно-ориентированными, или строго ориентированными на интерфейс, или строго ориентированными на аспект, или их комбинацией?
Некоторые приложения успешны, некоторые легко обслуживаются. Один из примеров, который я могу вспомнить, - это Artisan Studio, инструмент SysML, который был первым, кто внедрил его, но когда я пошел на собеседование, мне показалось, что он очень плохо обслуживается. Его дизайн - это стиль компонента OO C ++ - распределенная база данных OO, использующая COM для добавления функций в качестве компонентов; но они признались, что у них было много проблем при работе с большой устаревшей кодовой базой. Я подозреваю, что теперь гораздо более дешевый и гибкий UML-инструмент Enterprise Architect имеет SysML-предложение, которое приведет к снижению успеха. Я не разговаривал с дизайнерами EA, но EA построен на основе базы данных SQL, и API автоматизации, очевидно, не является чисто OO-решением - например, вы должны обновить разные части одного и того же свойства UML объект, использующий разные API (пакет UML представлен как объектом Package, так и элементом Element, и если вы изменяете имя пакета в одном API, вы должны помнить, чтобы изменить его в другом, иначе у него будет другое имя в дереве пакетов и на любой диаграмме). Учитывая скорость, с которой функции добавляются в EA, и общее качество приложения, я подозреваю, что оно будет более гибким, чем принятая Artisan модель «лучше ОО», но не может с легкостью провести рефакторинг.
Я не нахожу сильной связи между ремонтопригодностью и успехом или строгой OO и успехом. Делать то, что нужно, и возможность рефакторинга программного обеспечения, вероятно, важнее для успеха. Это и хороший отдел маркетинга.
(рефакторинг чего-то противоположен поддержанию чего-либо - при рефакторинге вы меняете архитектуру, но набор функций статичен; обслуживание включает добавление новых функций или удаление ошибок из существующей архитектуры)