Связь, сплоченность и закон Деметры

В ситуациях, когда кажется, что существует компромисс между связностью и сплоченностью, я бы, вероятно, спросил себя: «Если бы кто-то другой уже написал эту логику, и я искал в ней ошибку, куда бы я посмотрел в первую очередь?», И напишите код таким образом.

Если вы нарушаете Закон Деметры, имея

int price = customer.getOrder().getPrice();

решение состоит не в том, чтобы создавать getOrderPrice () и преобразовывать код в

int price = customer.getOrderPrice();

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

Я не знаю, действительно ли это снижает сплоченность.

Агрегация / композиция - это все о классе, использующем другие классы для выполнения контракта, который он предоставляет через свои общедоступные методы. Классу не нужно дублировать интерфейс связанных с ним объектов. Фактически он скрывает любые сведения об этих агрегированных классах от вызывающего метода.

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

Другими словами, каждый класс имеет одну или несколько зависимостей от других классов, однако это всегда зависимости только от указанного класса, а не от каких-либо объектов, возвращаемых из свойств / методов.

Я думаю, вы могли неправильно понять, что означает сплоченность. Класс, который реализован в терминах нескольких других классов, не обязательно имеет низкую сплоченность, если он представляет ясную концепцию и имеет ясную цель. Например, у вас может быть class Person, который реализован в терминах классов Date (для даты рождения), Address и Education (список школ, в которые пошел человек). Вы можете предоставить обертки в Person для получения года рождения, последней школы, в которой человек учился, или штата, в котором он живет, чтобы не раскрывать тот факт, что Person реализован с точки зрения этих других классов. Это уменьшило бы сцепление, но сделало бы Person не менее связным.

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

Сделайте так, чтобы это работало на вас, не работайте на это.

Грэди Буч в "Объектно-ориентированном анализе и дизайне":

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

Замените Dog на Customer в приведенном выше примере, и это может быть немного яснее. Таким образом, цель на самом деле состоит в том, чтобы стремиться к функциональной сплоченности и максимально уйти от случайной сплоченности. В зависимости от ваших абстракций это может быть просто или может потребоваться некоторый рефакторинг.

Обратите внимание, что сплоченность применима как к «модулю», так и к отдельному классу, то есть к группе классов, работающих вместе. Таким образом, в этом случае классы Customer и Order по-прежнему имеют приличную сплоченность, потому что у них есть сильные отношения, клиенты создают заказы, заказы принадлежат клиентам.

Мартин Фаулер говорит, что ему было бы удобнее назвать это «Предложением Деметры» (см. Статью Моки - это не заглушки):

«Тестировщики-имитаторы больше говорят об избежании« крушения поезда »- цепочек методов стиля getThis (). GetThat (). GetTheOther (). Избегание цепочек методов также известно как следование закону Деметры. Хотя цепочки методов - это запах, Противоположная проблема с объектами посредников, раздутыми методами пересылки, также является запахом (я всегда чувствовал, что мне было бы удобнее с Законом Деметры, если бы он назывался Предложение Деметры.) "

Это хорошо резюмирует то, откуда я пришел: совершенно приемлемо и часто необходимо иметь более низкий уровень сплоченности, чем может потребоваться строгое соблюдение «закона». Избегайте случайной сплоченности и стремитесь к функциональной сплоченности, но не зацикливайтесь на настройке там, где это необходимо, чтобы более естественно вписаться в абстракцию вашего дизайна.