converted to PDF by BoJIoc

17.4. Преднамеренное зацепление

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

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

Один из способов избежать слишком сильной взаимозависимости между связанными компонентами — использовать администратор зависимостей. Он является стандартной частью run-time библиотек в Smalltalk и Objective-C, но может быть легко сконструирован и для других языков (например, C++). Основная идея состоит в том, что администратор зависимостей действует как посредник, обслуживая список объектов и других компонент, от них зависящих. Модели требуется знать только об администраторе зависимостей. Объекты-отображения «регистрируют» себя с помощью администратора зависимостей, указывая при этом, что они зависят от объекта-модели. Впоследствии объект-модель при своем изменении посылает единственное сообщение администратору зависимостей. Тем самым последний узнает, что модель изменилась и все зависимые от нее компоненты должны быть оповещены об этом. Зависимые компоненты получают сообщения от администратора зависимостей, которые извещают, что модель изменилась и должны быть предприняты надлежащие действия.

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

Упражнения

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

2.Сильная форма закона Деметера запрещает доступ к экземплярам класса потомка. Опишите преимущества и недостатки этого ограничения. Рассмотрите такие моменты, как зацепление между классами и понятность кода программы.

3.Не кажется ли вам, что сильная форма закона Деметера должна ограничивать доступ также и к глобальным переменным? Обоснуйте свое мнение. Обдумывая ответ, вы можете обратиться к статье Вульфа и Шоу [Wulf 1973].

4.Какие еще можно предложить конкретные правила, аналогичные закону Деметера, такие, что:

oих выполнение обычно приводит к системам с меньшей взаимозависимостью;

o ситуации, когда правила должны нарушаться, встречаются редко.

Закон Деметера посвящен зацеплению между различными объектами. Можно ли предложить правила, которые стимулировали бы большую связность внутри объекта?