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

Question

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

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

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

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

Answer 1

• Является ли Demeter нереальным в любом сценарии сервер / клиент?

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

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

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

В некоторых случаях REST не самый лучший ответ, но REST в целом работает замечательно.

Answer 2

Ссылка, предоставляемая представлением, предоставляемым интерфейсом RESTful, может быть полностью непрозрачной без нарушения каких-либо ограничений REST. Поэтому я бы предположил, что 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 ограничивает возможности клиентов, предоставляя только допустимые ссылки в представлениях. В рамках этих ограничений клиент может попытаться удовлетворить свои собственные потребности. Именно удаляя знания от клиента о том, когда могут быть сделаны определенные запросы, вы достигаете слабой связи. Слабая связь не достигается путем перечисления набора ресурсов и произнесения «хорошо, вы можете ПОЛУЧИТЬ, ПОСТАВИТЬ, ПОСТАТЬ, УДАЛИТЬ все, что вы хотите».

Answer 3

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

Answer 4

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