Проблема:
Нужно распределить обязанности между классами таким образом, чтобы снизить взаимное влияние изменений в них и повысить возможность повторного использования.
Решение:
Следует распределить обязанности таким образом, чтобы обеспечить слабую связанность. Связанность (coupling) — это мера, определяющая насколько жестко один элемент связан с другими элементами, или каким количеством данных о других элементах он обладает. Элемент со слабой связанностью зависит от небольшого числа других элементов. Класс с сильной связанностью зависит от множества других классов. Наличие таких классов нежелательно, поскольку оно приводит к возникновению следующих проблем.
· Изменения в связанных классах приводят к локальным изменениям в данном классе.
· Затрудняется понимание каждого класса в отдельности.
· Усложняется повторное использование, поскольку для этого требуется дополнительный анализ классов, с которыми связан данный класс.
Пример:
Рассмотрим подчиненный поток событий «Создать график» варианта использования «Зарегистрироваться на курсы» (см. рис. 4.8). На данной диаграмме при создании нового графика в системе выбран вариант 1 (рис. 4.13). Однако согласно образцу «Low Coupling» наилучшим решением является вариант 2, поскольку при этом у класса RegistrationController будет на одну связь меньше (т.е. будет обеспечена более слабая связанность).
|
|
Следствия:
Образец Low Coupling поддерживает независимость классов, что, в свою очередь, повышает возможности повторного использования и обеспечивает более высокую эффективность приложения. Его нельзя рассматривать изолированно от других образцов, таких как Information Expert и High Cohesion. Он также обеспечивает выполнение одного из основных принципов проектирования, применяемых при распределении обязанностей.
Не существует абсолютной меры для определения слишком сильной связанности. Важно лишь понимать связанность объектов и не упустить тот момент, когда дальнейшее повышение связанности может привести к возникновению проблем. В целом следует руководствоваться таким принципом: классы, которые являются достаточно общими по своей природе и с высокой вероятностью будут повторно использоваться в дальнейшем, должны иметь минимальную связанность с другими классами.
Крайним случаем при реализации образца Low Coupling является полное отсутствие связывания между классами. Такая ситуация тоже нежелательна, поскольку основная идея объектного подхода выражается в системе связанных объектов, которые «общаются» между собой посредством передачи сообщений. При слишком частом использовании принципа слабого связывания система будет состоять из нескольких изолированных сложных активных объектов, самостоятельно выполняющих все операции, и множества пассивных объектов, основная функция которых сводится к хранению данных. Поэтому при создании объектно-ориентированной системы должна присутствовать некоторая оптимальная степень связывания между объектами, позволяющая выполнять основные функции посредством взаимодействия этих объектов.
|
|
Не следует применять данный образец, когда создаются связи с устойчивыми элементами. Сильная связанность с такими элементами не представляет проблемы. Например, приложение Java 2 Enterprise Edition можно жестко связать с библиотеками Java, поскольку они достаточно стабильны.
Сильная связанность сама по себе не является проблемой. Проблемой является жесткое связывание с неустойчивыми элементами. Важно понимать, что без убедительной мотивации не следует во что бы то ни стало бороться за уменьшение связанности объектов.