Здравствуйте, AlexRK, Вы писали:

ARK>Уважаемые форумчане. Интересует такой вопрос.

ARK>Есть ли в природе более формальное определение сабжа, нежели приведенное в википедии (http://en.wikipedia.org/wiki/Law_of_Demeter)?
Давно думал подискутировать на тему Law of Demeter. Но как-то поводу не возникало. Нет, более формального не встречал.

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

ARK>С другой стороны, мы можем возвращаемое значение записать в поле и тут же у этого поля вызвать метод — это вроде как не будет нарушением закона Деметры. Но выглядит это очень тупо.
Согласен. Тупо. Но формально (если мы используем конкретно эти формулировки) и не всякое поле подойдет. Глобальная переменная — подойдет. Поле объекта чей метод выполняется — нет. И это еще более тупо.

ARK>Еще непонятный момент с операторами. Например, в выражении "(a + b) / 3" оператор деления уже нарушает сабж.
формально — нет. Дело в том, что оператор деления "/" обычно не метод объекта результата суммы a и b. Вообще, когда мы вызываем статический метод (а оператор деления "/" обычно можно считать именно таковым), закон Деметры неприменим.

ARK>Предвижу возможные ответы типа "закон Деметры — это не закон, а рекомендация, надо применять его разумно, .....".
ARK>Такая позиция меня не интересует, интересно именно _формальное_ определение, если оно конечно существует. А если не существует, то интересны любые мнения по поводу того, каким оно могло бы быть.
Все верно, у "ЗАКОН"-а должна быть очень формальная формулировка, которая не допускает кривотолков и разночтений. ИМХО, никаких "придумай себе сам, когда это применять" не допустимо.

По поводу мнения, каким бы оно могло быть: думал по этому поводу. Некое рациональное зерно присутствует, но в форме "делай только так и будет счастье" слишком много иррационального. Плодить водопроводные методы a.BMethod() вместо a.b.Method() не видно вообще никакого резона. Особенно если это a.Name.Substring(...) или что-то вроде. Не делать же метод A.NameSubstring(...).