Образец «Low Coupling»

Проблема:

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

Решение:

Следует распределить обязанности таким образом, чтобы обеспечить слабую связанность. Связанность (coupling) — это ме­ра, определяющая насколько жестко один элемент связан с дру­гими элементами, или каким количеством данных о других элементах он обладает. Элемент со слабой связанностью зависит от небольшого числа других элементов. Класс с сильной связан­ностью зависит от множества других классов. Наличие таких классов нежелательно, поскольку оно приводит к возникнове­нию следующих проблем.

· Изменения в связанных классах приводят к локальным из­менениям в данном классе.

· Затрудняется понимание каждого класса в отдельности.

· Усложняется повторное использование, поскольку для это­го требуется дополнительный анализ классов, с которыми связан данный класс.

Пример:

Рассмотрим подчиненный поток событий «Создать график» варианта использования «Зарегистрироваться на курсы» (см. рис. 4.8). На данной диаграмме при создании нового графика в систе­ме выбран вариант 1 (рис. 4.13). Однако согласно образцу «Low Coupling» наилучшим решением является вариант 2, поскольку при этом у класса RegistrationController будет на одну связь мень­ше (т.е. будет обеспечена более слабая связанность).

Следствия:

Образец Low Coupling поддерживает независимость классов, что, в свою очередь, повышает возможности повторного исполь­зования и обеспечивает более высокую эффективность приложе­ния. Его нельзя рассматривать изолированно от других образцов, таких как Information Expert и High Cohesion. Он также обеспечи­вает выполнение одного из основных принципов проектирова­ния, применяемых при распределении обязанностей.

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

Крайним случаем при реализации образца Low Coupling явля­ется полное отсутствие связывания между классами. Такая ситуа­ция тоже нежелательна, поскольку основная идея объектного подхода выражается в системе связанных объектов, которые «об­щаются» между собой посредством передачи сообщений. При слишком частом использовании принципа слабого связывания система будет состоять из нескольких изолированных сложных активных объектов, самостоятельно выполняющих все опера­ции, и множества пассивных объектов, основная функция кото­рых сводится к хранению данных. Поэтому при создании объект­но-ориентированной системы должна присутствовать некоторая оптимальная степень связывания между объектами, позволяю­щая выполнять основные функции посредством взаимодействия этих объектов.

Не следует применять данный образец, когда создаются связи с устойчивыми элементами. Сильная связанность с такими эле­ментами не представляет проблемы. Например, приложение Java 2 Enterprise Edition можно жестко связать с библиотеками Java, поскольку они достаточно стабильны.

Сильная связанность сама по себе не является проблемой. Проблемой является жесткое связывание с неустойчивыми эле­ментами. Важно понимать, что без убедительной мотивации не следует во что бы то ни стало бороться за уменьшение связаннос­ти объектов.