Закон Деметры против ОТДЫХА

Закон Деметры (на самом деле должен быть предложением Деметры) гласит, что вы не должны «протягивать руку» через объект, чтобы добраться до их дочерних объектов. Если вам, как клиенту, необходимо выполнить какую-то нетривиальную операцию, большую часть времени модель предметной области, с которой вы работаете, должна поддерживать эту операцию.

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

Итак, как вы сбалансируете REST и Demeter? Мне кажется, что они не конфликтуют, потому что REST - это сверхслабое связывание до такой степени, что поставщику бессмысленно пытаться предугадывать все потребности клиентов, тогда как Деметер предполагает, что логика может перейти на его самое естественное место за счет рефакторинга.

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


rest law-of-demeter
person David Gladfelter    schedule 14.04.2009    source источник
comment
Это сравнение яблок и апельсинов. REST - это создание масштабируемых распределенных систем с использованием единого интерфейса. Закон Деметры касается уменьшения связи между частями системы.   -  person Don McCaughey    schedule 14.04.2009
comment
Вы думаете о ситуации, когда клиент создает URL-адрес для дочернего объекта вместо того, чтобы передать ему дочерний URL-адрес? Я думаю, это было бы нарушением, но не в том случае, если URL-адрес является результатом родительской операции.   -  person John Saunders    schedule 14.04.2009

Ответы (4)


arrow_upward
5
arrow_downward

  • Деметра нереалистична в любом сценарии сервер / клиент?

Думаю, вы здесь ответили на свой вопрос. Чем REST в этом отношении отличается от SOAP или XML-RPC в этом отношении?

Смысл REST не в том, чтобы обеспечить сверхслабое сцепление, а в следующем:

  • Укажите идентификатор, который точно описывает запрашиваемый ресурс.
  • Предоставлять услуги, которые работают должным образом GET запросы являются идемпотентными, PUT записи обновляются, POST создает, DELETE удаляет
  • Минимизировать состояние, хранящееся на сервере
  • Снесите ненужную сложность

Бывают случаи, когда REST не лучший ответ, но REST в целом работает замечательно.

person cgp    schedule 14.04.2009
comment
Я имею в виду REST в смысле любого механизма доступа к объектам на основе URL. URL-адрес является нарушением Деметры. - person David Gladfelter; 14.04.2009
comment
Все хорошие моменты, спасибо. Думаю, я имел в виду глубокие иерархии REST. Не все REST должны быть такими, но я работаю над проектом, который использует модель на основе URI для слабосвязанной системы, и меня беспокоит, что можно использовать глубокую иерархию, чтобы лучше не понимать потребности клиентов. - person David Gladfelter; 14.04.2009

arrow_upward
2
arrow_downward

Я совершенно не обращаю внимания на этот закон / предложение. Это сводит на нет половину преимуществ агрегирования и композиции, и я этого не допущу.

person chaos    schedule 14.04.2009
comment
На самом деле IMAO это антипаттерн. - person chaos; 14.04.2009
comment
Я бы не пошел так далеко. Если вы действительно получаете доступ к частным частям классов, это делает систему более хрупкой. это не означает, что у вас не может быть методов в сигнатуре класса, которые просто вызывают методы агрегированного класса. - person Charlie Martin; 14.04.2009

arrow_upward
2
arrow_downward

Ссылка, предоставляемая представлением, предоставляемым интерфейсом RESTful, может быть полностью непрозрачной без нарушения каких-либо ограничений REST. Поэтому я бы предположил, что ОТДЫХ полностью соответствует Закону Деметры. Не требуется, чтобы ссылка раскрывала структуру пространства URL-адресов в своем URL-адресе.

например в объектно-ориентированном сценарии вы можете заменить вызов a.b.c на a.bc

В представлении RESTful вы можете создать следующее:

<a>
  <link href="bc"/>
</a>

вместо того, чтобы делать

GET a

    <a>
      <link href="b"/>
    </a>

GET b

    <b>
      <link href="c"/>
    </b>

GET c

Я бы не согласился с altCognito и сказал, что одна из основных целей REST - слабая связь. Единый интерфейс, стандартные типы носителей и HATEOAS - все это вместе дает чрезвычайно слабосвязанный интерфейс.

В ответ на комментарий Дэвида:

REST - это сверхслабая связь до такой степени, что поставщику бессмысленно пытаться предугадывать все потребности клиентов.

Фактически, REST ограничивает возможности клиентов, предоставляя только действительные ссылки в представлениях. В рамках этих ограничений клиент может попытаться удовлетворить свои собственные потребности. Слабая связь достигается за счет удаления у клиента информации о том, когда могут быть сделаны определенные запросы. Слабое связывание не достигается перечислением набора ресурсов и словами «хорошо, вы можете ПОЛУЧИТЬ, ПОЛУЧИТЬ, ОТПРАВИТЬ, УДАЛИТЬ все, что захотите».

person Darrel Miller    schedule 14.04.2009

arrow_upward
1
arrow_downward

Я думаю, они действительно ортогональны. REST описывает набор ресурсов, адресованных URI, с помощью набора канонических методов: GET, POST и т. Д. Если подпрограмма REST возвращает URI, это не «проходящий через», а идентификация другого объекта с такими же именами методов.

person Charlie Martin    schedule 14.04.2009