Закон Деметры в дизайне API для C ++

Часто используется аналогия (в том числе на странице Википедии, как я заметил): вы просите собаку выгуливать - вы спрашиваете собаку, вы не просите доступа к ее ногам, а затем просите ее ноги выгуливать.

Лучше попросить собаку выгуливать, потому что однажды вы можете захотеть собаку с чем-то другим, кроме ног.

В вашем конкретном примере реализация m_A может перестать зависеть от экземпляра B.

РЕДАКТИРОВАТЬ: поскольку некоторые люди хотят дальнейшего изложения, позвольте мне попробовать это:

Если объект X содержит оператор m_A.GetObjectB().DoSomething(), тогда X должен знать:

1. этот m_A имеет экземпляр объекта B, представленного через GetObject(); и
2. что объект B имеет метод DoSomething().

Итак, X необходимо знать интерфейсы A и B, а A всегда иметь возможность продавать B.

И наоборот, если X просто нужно было сделать m_A.DoSomething(), то все, что ему нужно знать, это:

1. что m_A имеет метод DoSomething().

Таким образом, закон способствует разъединению, потому что X теперь полностью отделен от B - ему не нужно ничего знать об этом классе - и меньше знаний о A - он знает, что A может достичь DoSomething(), но ему больше не нужно знать, делает ли он это сам или просит ли это сделать кто-то еще.

На практике закон часто не используется, потому что он обычно означает просто написание сотен функций-оболочек, таких как A::DoSomething() { m_B.DoSomething(); }, а формальная семантика вашей программы часто явно диктует, что A будет иметь B, поэтому вы не так сильно раскрываете детали реализации, предоставляя GetObjectB() поскольку вы просто выполняете контракт этого объекта с системой в целом.

Первый пункт также можно использовать, чтобы утверждать, что закон увеличивает связь. Предположим, у вас изначально было m_A.GetObjectB().GetObjectC().GetObjectD().DoSomething(), и вы свернули его до m_A.DoSomething(). Это означает, что, поскольку C знает, что D реализует DoSomething(), C должен это реализовать. Затем, поскольку B теперь знает, что C реализует DoSomething(), B должен это реализовать. И так далее. В конце концов, вам нужно A реализовать DoSomething(), потому что D это делает. Итак, A в конечном итоге вынужден действовать определенным образом, потому что D действует определенным образом, тогда как раньше он мог ничего не знать о D.

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

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

Чтобы напрямую ответить на ваш вопрос:

Версия 2 создает более слабосвязанные классы, потому что Func в первом случае зависит как от интерфейса класса m_A, так и от класса возвращаемого типа GetObjectB (предположительно ObjectB), тогда как во втором случае это зависит только от интерфейса класса ObjectB.

То есть в первом случае существует связь между классом m_A и Func, во втором случае - нет. Если интерфейс этого класса должен когда-либо измениться, чтобы не иметь GetObjectB(), но, например, чтобы иметь GetFirstObjectB() и GetSecondObjectB(), в первом случае вам придется переписать Func для вызова соответствующей функции замены (и, возможно, даже добавить некоторую логику, которую следует вызывать, возможно, на основе дополнительного аргумента функции), а во второй версии вы может оставить функцию как есть и позволить пользователям Func заботиться о том, как получить этот объект типа ObjectB.

Разница становится еще больше, если посмотреть на модульные тесты.

Предположим, что DoSomething() имеет побочный эффект, который вы не хотите иметь в своем тестовом коде, потому что было бы дорого или раздражающе моделировать, например, доступ к базе данных или сетевое взаимодействие.

В первом случае, чтобы заменить DoSomething() в вашем тесте, вам нужно подделать и ObjectA, и ObjectB и внедрить поддельный экземпляр ObjectA в класс, содержащий Func().

Во втором случае вы просто вызываете Func() с поддельным экземпляром ObjectB, что значительно упрощает тест.

Он более гибкий к изменениям. Представьте, что m_A - это экземпляр объекта A, разработанный программистом Бобом. Если он решит внести изменения в свой код, чтобы A больше не имел метода для возврата объекта типа B, то Алисе, разработчику Func, также придется изменить свой код. Обратите внимание, что у вас нет этой проблемы с последним фрагментом кода.

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

Что ж, я думаю, должно быть очевидно, почему объединение функций в цепочку - это плохо, так как при этом становится труднее поддерживать код. В верхнем примере Func() - уродливая функция, потому что кажется, что она будет вызываться просто как

Func();

По сути, ничего не говорит вам о функции. Второй предложенный метод вызывает функцию с переданным ему B, что не только делает его более читаемым, но и означает, что вы можете написать Func() для других классов, не переименовывая его (поскольку, если он не принимает никаких параметров, вы не можете переписать его для другого класс). Это говорит вам, что Func() будет делать аналогичные вещи с объектом, даже если класс отличается.

Чтобы ответить на последнюю часть вашего вопроса, слабая связь достигается, потому что первый пример подразумевает, что вы должны получить от B до A, которые объединяют классы вместе, второй пример является более общим и подразумевает, что B может поступать откуда угодно.