Цель дизайна

Цель объектно-ориентированного дизайна (OOD) - разрабатывать программное обеспечение с низкой стоимостью изменения. Плохо спроектированный код и хорошо спроектированный код могут решить одну и ту же проблему и предоставить одни и те же функции из определенного списка требований. Но когда позже будет добавлен другой набор требований, стоимость интеграции новых изменений со старым кодом будет намного выше в случае плохо спроектированного кода. Другими словами, чем выше стоимость изменения, тем хуже разработан код.

Как определяется термин «стоимость»? Как мы узнаем, сколько «стоит» сдача? Об этом можно думать так: учитывая новое требование и существующую в настоящее время базу кода, представьте, что все, что вам нужно сделать, это написать новый код, который напрямую реализует новую функцию, и приложение волшебным образом будет работать именно так, как должно. Это сделало бы изменение нулевым. Теперь представьте, что для реализации этой функции требуется использование пары настраиваемых классов в базе кода. Оказывается, реализация этого настраиваемого класса была написана не с расчетом на то, что он будет использоваться этим новым способом, поэтому использование его таким новым способом фактически вызовет ошибку. Реализация новой функции теперь является не только вопросом прямой реализации, но и косвенным «ремонтом», так что реализация новой функции не вызовет ошибку при использовании ранее существовавшего настраиваемого класса. Это изменение дороже, чем в первом сценарии.

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

Если кодовая база никогда не нуждалась в изменении, то термин «дизайн» был бы бессмысленным. Тот факт, что код необходимо изменить, - это основная проблема, которую решает дизайн.

Твердо зная «почему» объектно-ориентированного дизайна, мы можем перейти к «как» в следующей статье этой серии (следите за ее выпуском).