Проблема "ограничения по совпадению"

Иногда наследование применяется для выражения связанных с конкретным приложением вариантов класса. При этом достигается множественность повторного использования.

Разумеется, таким способом тоже можно явно выразить общность, но какой ценой?

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

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

Наследование — эффективный механизм, предназначенный для выражения отношений обобще­ния-ограничения, связанных с конкретной областью, а не для ограничения по совпадению.

Нужно найти лучший способ работы с механизмом обобщения па множестве приложений.

Проблема "то один вид, то другой"

Иногда разработчики стремятся к тому, чтобы o67ieK'r изменялся сам, постепенно конвертируя себя из одного ограничения в другое.

Для этого требуется огромное множество служб создания, копирования и удаления. При этом не­возможно зафиксировать, что происходит с течением времени.

Лучше добавить к модели объект, играющий множество ролей (шаблоном такого подхода может быть образец актер-участник).

Проблема "эффект мелкой волны"

Случается, разработчики забывают, что изменения в классах обобщения могут сильно влиять на то, что находится ниже в иерархии классов. Эти изменения распространяются волной на классы ограни­чения и далее вниз по иерархии классов (на средства тестирования в том числе). Именно поэтому имеет смысл применять неглубокие (до четырех уровней) структуры обобщения-ограничения, свя­занные с конкретной областью. Вот почему метод "ограничения по совпадению" распадается так бы­стро (при десяти или двадцати уровнях ограничений, связанных с конкретной областью, "эффект мелкой волны" становится похожим больше на "эффект волны прилива").

Наследование — это тотальное бедствие?

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

Наследование окупается, если применяется в разумном контексте

Используйте наследование в единственном приложении для отображения отношений обобще­ния-ограничения в конкретной области. Не задействуйте его для управления представлением (пока­зывающим, с чем вы хотите работать в специальном приложении).

Наследование разрушается, когда оно применяется для:

— выделения общности без учета связанного с конкретной областью обобщения-ограничения;

• отображения представлений, связанных с конкретным приложением.

Механизм повторного использования #2: компоненты

В данном случае объект состоит из нескольких компонентов.

Приведем простой пример. Возможно, в повседневных разговорах вы слышали, как человек гово­рит обо всех головных уборах, которые он носит. Данный объект (человек) в обыденной жизни носит разные головные уборы. Обязанности этого объекта представлены множеством форм участия.

Образец "актер-участник" — это шаблон для повторного использования, основанного на конкрет­ном компоненте.

Повторное использование компонентов особенно полезно, когда оно проводится на множестве приложений. Для каждого приложения выбираются компоненты, с которыми необходимо работать.