Связь, сцепление и закон Demeter
6 ответов
Grady Booch в "Объектно-ориентированном анализе и проектировании":
"Идея сцепления также прибывает из структурного проектирования. Просто указанный, сцепление измеряет степень возможности соединения среди элементов единственного модуля (и для объектно-ориентированного дизайна, единого класса или объекта). Наименее желательная форма сцепления является случайным сцеплением, в которое совершенно несвязанные абстракции брошены в тот же класс или модуль. Например, рассмотрите класс, включающий абстракции собак и космического корабля, поведения которого довольно не связаны. Самая желательная форма сцепления является функциональным сцеплением, в котором элементы класса или модуля все сотрудничают для обеспечения некоторого хорошо ограниченного поведения. Таким образом класс Собака функционально связен если ее объятие семантики поведение собаки, целой собаки, и только собаки".
Собака Subsitute с Клиентом в вышеупомянутом и это могло бы быть немного более ясно. Таким образом, цель состоит в том, чтобы действительно только стремиться к функциональному сцеплению и переезжать от случайного сцепления как можно больше. В зависимости от Ваших абстракций это может быть просто или могло потребовать некоторого рефакторинга.
сцепление Примечания применяется так же к "модулю", чем к единому классу, т.е. группе сотрудничества классов. Таким образом, в этом случае классы Клиента и Порядка все еще имеют достойное сцепление, потому что у них есть этот сильный relationshhip, клиенты создают заказы, заказы принадлежат клиентам.
Martin Fowler говорит, что был бы более удобным вызовом его "Предложение Demeter" (см., что Насмешки статьи не являются тупиками ):
"тестеры Mockist действительно говорят больше о предотвращении 'железнодорожных аварий' - цепочки метода стиля getThis () .getThat () .getTheOther (). Предотвращение цепочек метода также известно как в соответствии с Законом Demeter. В то время как цепочки метода являются запахом, противоположной проблемой средних объектов мужчин, чрезмерно увеличенных в размере с передачей методов, является также запах. (Я всегда чувствовал, что был бы более доволен Законом Demeter, если бы это назвали Предложение Demeter.)"
, Который подводит итог приятно, куда я происхожу из: это совершенно приемлемо и часто необходимо иметь более низкий уровень сцепления, чем строгое соблюдение "закона" могло бы потребовать. Избегайте случайного сцепления и стремитесь к функциональному сцеплению, но не становитесь одержимыми тонкой настройкой при необходимости для согласований более естественно с абстракцией дизайна.
При нарушении Закона Demeter при наличии
int price = customer.getOrder().getPrice();
, решение не состоит в том, чтобы создать getOrderPrice () и преобразовать код в
int price = customer.getOrderPrice();
, но вместо этого отметить, что это запах кода , и внесите соответствующие изменения что, надо надеяться, оба сцепления увеличения и более низкая связь. К сожалению, нет никакого простого рефакторинга здесь, который всегда применяется, но необходимо, вероятно, подать заявку , говорят, не спрашивают
Я думаю, что Вы, возможно, неправильно поняли то, что означает сцепление. Класс, который реализован с точки зрения нескольких других классов, не обязательно имеет низкое сцепление, пока это представляет ясное понятие и имеет ясную цель. Например, Вы можете иметь class Person, который реализован с точки зрения классов Date (для даты рождения), Address, и Education (список школ, человек перешел в). Можно обеспечить обертки в Person для получения года рождения, последняя школа, человек перешел в, или состояние, где он живет, чтобы не представлять то, которое Person реализовано с точки зрения тех других классов. Это уменьшило бы связь, но она сделает Person не менее связный.
It’s серая область. Эти принципалы предназначены для помощи Вам в Вашей работе при нахождении you’re, работающего на них (т.е. стоящий на пути they’re, и/или Вы находите, что это усложняет Ваш код), тогда you’re приспосабливание слишком трудно, и необходимо отступить.
Делают, это работать на Вас, don’t работает на него.
Я не знаю, понижает ли это на самом деле сцепление.
Агрегирование/состав - все о классе, использующем другие классы для соблюдения контракта, который оно представляет через его открытые методы. Класс не должен копировать интерфейс, он связал объекты. Это на самом деле скрывает любой knwowledge об этих агрегированных классах от вызывающей стороны метода.
Для подчинений закону Demeter в случае нескольких уровней зависимости от класса просто необходимо применить агрегирование/состав и хорошую инкапсуляцию на каждом уровне.
, Другими словами, каждый класс имеет одну или несколько зависимостей от других классов, однако это только когда-либо зависимости от класса, на который ссылаются, а не от любых объектов, возвращенных из properies/methods.
В ситуациях, где, кажется, существует компромисс между связью и сцеплением, я, вероятно, спросил бы меня, "если бы кто-то еще уже записал эту логику, и я искал ошибку в нем, где я выглядел бы первым?", и запись код тот путь.