Возвращаясь к теме семинаров по ООП, хочу коснуться такой темы как ошибки проектирования системы. Как и раньше надеюсь увидеть ваши предложения и пожелания.

Большинство авторов, которых я читал, сходятся в том, что основная ошибка программистов при проектировании системы заключается в использовании решений, которые делают систему невосприимчивой к будущим изменениям. Иначе говоря, главный признак хорошей системы — это ее открытость для изменений.

Я не буду придумывать велосипед и пытаться обобщить свой опыт с целью найти причины, приводящие к проблемам перепроектирования. По той простой причине, что эту задачу успешно решили до меня. Далее я приведу основные ошибки, описанные в книге «Design patterns Elements of reusable object-oriented software» E.Gamma, R.Helm, R.Johnson, J.Vlissides:

• при создании объекта явно указывается класс

Указывая конкретный класс, мы привязываемся к его реализации. Гораздо лучше использовать интерфейс, тогда мы можем использовать любой класс, реализующий заданный интерфейс.

• зависимость от конкретных операций

Задавая конкретную операцию, мы ограничиваем себя единственным способом ее выполнения. Желательно продумывать интерфейс таким образом, чтобы контекст объекта в большей мере задавался его конструктором.

• зависимость от программных и аппаратных платформ

Непосредственное использование внешних библиотек создает слишком жесткую связь. Лучше такие библиотеки использовать опосредованно.

• зависимость от представления или реализации объекта

Если клиент знает особенности реализации используемого объекта, возникает соблазн использовать эти знания. Здесь явно нарушается инкапсуляция, со всеми вытекающими.

• зависимость от алгоритмов

Если используемый алгоритм имеет высокие шансы на изменение, его следует изолировать. Иначе в будущем его будет сложно изменить.

• сильная связанность

Сильно связанные классы очень трудно использовать отдельно. Если количество связанных классов незначительно, то это не страшно. В противном случае однозначное зло.

• расширение функционала за счет порождения подклассов

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

• неудобства при изменении класса

Если класс неудобно модифицировать, то скорее всего он не будет модифицирован никогда.

Хочется обратить внимание на то, что создать абсолютно чистую программу, открытую для любых изменений, нельзя! В той или иной мере указанные выше недостатки присутствуют в любой системе. Задача программиста заключается в том, чтобы во время разработки программы определить некий вектор будущего развития и приложить все усилия, чтобы движение по этому направлению было максимально легким. В этом очень хорошо помогают шаблоны проектирования и рефакторинг, но о них поговорим в другой раз.