Объектно-ориентированное проектирование сосредоточено на сообщениях, которыми обмениваются объекты, при этом сообщениям отводится главная роль. Обмен сообщениями подразумевает, что отправитель знает что-то о получателях, а это знание является зависимостью. Зависимости усложняют внесение изменений, так как требуют изменять классы, зависящие от только что изменённого.

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

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


Объекты, слишком много знающие об “окружающем мире”, требуют слишком многого. Эти требования ограничивают возможность их переиспользования и изменения, а также изолированного тестирования.

Значит, объекты должны знать как можно меньше о своем окружении.

Невежественный код


@design-purpose

Задача проектирования состоит из двух частей: 1) необходимо спроектировать и написать код, который будет работать сегодня; 2) этот код должно быть просто поддерживать и изменять завтра. Поскольку будущее неопределено и мы не можем предвидеть изменения, которые потребуются завтра (а они точно потребуются), то идеальный дизайн должен сохранять пространство для манёвра в будущем. Его главная цель - снизить стоимость изменений.

Каждое принятое решение сокращает “степени свободы”, поэтому хорошая архитектура должна минимизировать количество принятых проектных решений (см. Архитектура ПО как совокупность отложенных решений и Критерии качества архитектуры ПО).