Лекция № 6 Основные элементы объектного подхода к проектированию программ

Лекция № 6
Основные элементы объектного подхода
к проектированию программ
Три кита ООП подхода с точки зрения проектирования:
Наследование и композиция.
Достоинства и недостатки - наследование.

Определяется статически на этапе компиляции.

Проще поддерживать, так как оно напрямую реализуется через
язык программирования.

Упрощается задача модификации существующей реализации.



Нельзя изменить унаследованную реализацию во время
исполнения, так как она определяется на этапе компиляции.
Родительский класс по крайней мере частично определяет
реализацию своих подклассов. Таким образом наследование
НАРУШАЕТ инкапсуляцию.
Зависимость от реализации – опасность каскадного
изменения.
Три кита ООП подхода с точки зрения проектирования:
Наследование и композиция.
Достоинства и недостатки - композиция.

Определяется динамически во время выполнения за счет того,
что объекты получают ссылки на другие объекты.

Доступ к объектам осуществляется только через их
интерфейсы, следовательно, не нарушается инкапсуляция.

Во время исполнения один объект можно всегда заменить
другим, если он имеет тот же тип.

При реализации объекта в первую очередь кодируются его
интерфейсы, следовательно зависимость от реализации
снижается.

Каждый класс в этом случае инкапсулирует только свое
поведение (не тащит память об унаследованном). Классы
становятся не большими и не разрастаются до неуправляемых
размеров

Требуется тщательное проектирование интерфейсов, чтобы
один объект можно было использовать со множеством других.

В дизайне, скорее всего, будет несколько меньше классов, но
для реализации взаимодействия потребуется больше
объектов.
Три кита ООП подхода с точки зрения проектирования:
Наследование и композиция.
Второй принцип ОО-проектирования:
Композицию стоит предпочитать наследованию классов.
Идеал: чтобы добиться абсолютного повторного использования не
порождать новых классов совсем, а пользоваться только тем,
что есть. Было бы совсем замечательно, если бы всю новую
функциональность можно было бы, собирая вместе только те
классы, которые есть.
На практике такой абсолютизм практически неприменим, так как
готовых классов все-таки маловато будет. Повторное
использование за счет наследования упрощает создание
новых классов на базе старых. Наследование и композиция
используются совместно. Но теперь понятно, кто рулит в этой
парочке с точки зрения правильного дизайна.
Делегирование – прием повторного использования, который
позволяет сделать придать композиции свойства
наследования.
Три кита ООП подхода с точки зрения проектирования:
Типичные причины перепроектирования.
Проектирование с учетом последующих изменений:
Системы необходимо разрабатывать с учетом их дальнейшего
развития. Для того, чтобы сделать систему устойчивой к таким
изменениям, необходимо оценить, как она будет развиваться с
течением времени.
Если такая оценка не делается, то эволюция системы может
привести к полному редизайну системы. А это, во-первых,
муторно, а, во-вторых, дорого.
Разбираем типовые причины, которым могут привести к
перепроектированию:

При создании объекта явно указывается класс. Задание
имени класса привязывает вас к конкретной реализации, а не к
конкретному интерфейсу. Это может усложнить изменение
объекта в будущем. Чтобы уйти от такой проблемы стоит
создавать объекты косвенно. (Типовые приемы
проектирования для этих целей: абстрактная фабрика,
фабричный метод, прототип).
Три кита ООП подхода с точки зрения проектирования:
Типичные причины перепроектирования.

Зависимость от конкретной операции. Задавая конкретную
операцию вы ограничиваете себя единственным способом выполнения
запроса. Если не включать запросы в код, то будет проще изменять
способ выполнения запроса как на этапе компиляции, так и на этапе
выполнения. (Типовые приемы проектирования для этих целей:

цепочка обязанностей, команда).
Зависимость от аппаратной и программной платформ. Внешние
интерфейсы операционной системы и интерфейсы прикладных программ
(API) различны для разных аппаратных и программных платформ. Если
информационная система зависит от конкретной платформы, то ее будет
сложно перенести на другие, даже на «родной» платформе могут
возникнуть проблемы с ее поддержкой. Следовательно, при
проектировании систем стоит ограничивать платформенные зависимости.
(Типовые приемы проектирования для этих целей: абстрактная
фабрика, мост).
Три кита ООП подхода с точки зрения проектирования:
Типичные причины перепроектирования.

Зависимость от представления или реализации объекта. Если
«клиент» знает, как объект представлен, храниться или реализован, то
при изменении объекта может потребоваться изменить и клиента.
Сокрытие такой информации от клиента может уберечь от
последовательности каскадных изменений. (Типовые приемы

проектирования для этих целей: абстрактная фабрика, мост,
хранитель, заместитель).
Зависимость от алгоритмов. Во время разработки и последующего
использования алгоритмы часто расширяются, модифицируются и
оптимизируются. Зависящие от алгоритмов объекты приходится
переписывать при каждом изменении алгоритма. Следовательно
алгоритмы, вероятность изменения которых высока необходимо
изолировать. (Типовые приемы проектирования для этих целей:
мост, итератор, стратегия, шаблонный метод, посетитель).
Три кита ООП подхода с точки зрения проектирования:
Типичные причины перепроектирования.

Сильная связанность. Сильно связанные между собой классы трудно
использовать по раздельности, так как они сильно зависят друг от друга.
Сильная связанность приводит к появлению монолитных систем, в
которых нельзя ни изменить, ни удалить класс, без знания деталей и
модификации других классов. Такие системы трудно изучать,
модифицировать, переносить на другие платформы и сопровождать.
Слабая связанность повышает вероятность повторного использования
класса самого по себе. При этом изучение, модификация, перенос и
поддержка системы становится проще. Для поддержки слабо связанных
систем в ООП применяются такие приемы как абстрактные связи и
разбиение на слои. (Типовые приемы проектирования для этих
целей: абстрактная фабрика, мост, цепочка обязанностей,
команда, фасад, посредник, наблюдатель).
Три кита ООП подхода с точки зрения проектирования:
Типичные причины перепроектирования.

Расширение функциональности за счет порождения подклассов.
Специализация объекта путем создания подкласса очень часто
оказывается не очень простой операцией. С каждым новым подклассом
связаны некоторые фиксированные издержки реализации. Для
определения подкласса необходимо четко знать устройство
родительского класса. Кроме того такой способ приводит к
комбинаторному росту числа классов. Композиция объектов и
делегирование – гибкая альтернативы наследованию для
комбинирования поведений. Приложению можно добавить новую
функциональность изменяя способ композиции объектов, а не добавляя
новые подклассы. С другой стороны интенсивное использование этого
приема делает код трудным для понимания. Существует достаточно
много способов, когда специализация достигается за счет добавления
одного подкласса и комбинирования его экземпляров с уже
существующими. (Типовые приемы проектирования для этих целей:
мост, цепочка обязанностей, компоновщик, декоратор,
наблюдатель, стратегия).
Три кита ООП подхода с точки зрения проектирования:
Типичные причины перепроектирования.

Неудобство в изменении классов. Иногда нужно модифицировать
класс, но делать это неудобно. Например, нужен исходный код, а
его нет. Или любое изменение грозит каскадом модификаций.
(Типовые приемы проектирования для этих целей: адаптер,
декоратор, посетитель).