2.4.1.Повторное использование

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

Понятность

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

— с выбора имен классов, связанных с конкретной областью;

— с выбора менее ограниченных имен классов (имя обобщается, когда применимы одни и те же обязанности);

• с выбора обобщения-ограничения, связанного с конкретной областью.

Детали повторного использования

Повторно можно использовать:

— атрибут;

— службу;

— класс;

— образец (шаблон группы взаимодействующих объектов);

— экземпляр образца (заполненный шаблон, группу взаимодействующих объектов);

• сценарий (вероятнее, конкретную часть сценария).

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

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

Существуют следующие механизмы повторного использования:

— наследование;

— компоненты;

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

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

Наследование выражает, "что общего и в чем разница". Этот механизм применялся в задаче о магазин:

— цена, ограниченная до рекламной цены;

— экземпляр строки продажи, ограниченный до экземпляра строки возврата;

• оплата, ограниченная до оплаты наличными и авторизованной оплаты;

• авторизованная оплата, ограниченная до оплаты по чеку и по кредитной карточке.

Каждый класс обобщения отражает общие атрибуты, службы и связи между объектами, а каждый класс ограничения — дополнительные атрибуты, службы и связи. Класс обобщения явно показывает то, что является общим. Наследование не всегда является наилучшим механизмом повторного использования.

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

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

Примеры:

— имя есть у клиента и у корабля, поэтому добавляется класс "именованный предмет";

— у клиента есть адрес, и у корабля есть место расположения, поэтому добавляется класс "предметы, имеющие местоположение";

— статус есть и у клиента, и у корабля, поэтому добавляется класс "объект, имеющий статус".

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

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

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