Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, samius, Вы писали:
ARK>>>А в чем в таком случае смысл закона? Мы все равно вызываем нужный нам метод, просто "per rectum".
S>>Именно в этом и смысл, что "per rectum" можно, а намрямую — нет.
ARK>Ну, если рассматривать чисто эти 5 пунктов определения, то да, они допускают и такую трактовку.
ARK>Хотя там же написано: "If the law is followed, only object B knows its own internal structure".
ARK>Да и во всех других обсуждениях пишут аналогичное, например тут: http://c2.com/cgi/wiki?LawOfDemeter
Все понятно, все законы придумываются ради мира во всем мире и что бы всем сделать зашибись.
Но из формальных критериев применения следует что в некоторых случаях вызывать метод через точку вредно, а точно такой же метод но с передачей явного параметра вместо this — не вредно. Хотя методы могут быть при этом совершенно идентичные, вызывая через точку мы каким-то образом передаем знания о внутренней структуре объекта B в наш метод, а вызывая без точки — не передаем. В чем подвох, я так и не понял.
ARK>Мало того, в таком случае получается, что мы можем вызывать любые цепочки методов — мы ведь просто вызываем статические методы класса в засахаренном виде. Определение становится бессмысленным. Значит в нем явно чего-то не хватает.
S>>Нет, формально присвоение локальной переменной не разрешает дергать этот метод. А в глобальную — разрешает.
ARK>Ну что же, локальные переменные LoD вообще запрещает использовать? 
ARK>Про них ничего не написано, да, но что-то с ними можно делать?
Можно, но формулировка закона касается того, каким образом был получен объект, а не того, как его хранить в локальных переменных.
ARK>Ну, если уж подходить с позиций буквоедства, то в определении не сказано, что мы имеем право присваивать глобальные переменные и передавать объекты в другие методы (так же, как не сказано про поля объекта). Вызывать методы у глобальных переменных можем, да. А присваивать — вовсе не факт.
А что может запретить записывать в глобальную переменную? Она ведь вроде по умолчанию именно "переменная" и не указано что она readonly/const.
ARK>Так что формальное определение не то что сводит к абсурду, оно просто неполное и допускает разные трактовки.
А есть ли трактовка, которая объясняет чем вызов через точку вреднее явной передачи параметра?
ARK>Тут можно конечно высосать из пальца "трактовку", что "2 + 3" равносильно созданию объекта в текущем методе. Правда, тогда то же самое можно сказать о любых значениях, которые были возвращены вызванными методами.
Фиг с ними с "2+3", хотелось бы разобраться с общим случаем 2.Add(3).Div(5)
S>>Может и не стоит, но LoD ставит их как раз отдельной кастой. Раз статический объект не может быть "получен" и "передан", его методы можно вызывать без каких-либо ограничений, невзирая на соображения о знаниях на счет "внутреннего устройства" такого объекта.
ARK>Опять же, строго говоря, в определении про это ничего нет. Ни в один из 5 пунктов статические объекты не помещаются. Не факт, что мы должны их по умолчанию разрешить, может быть наоборот?
Все-таки статические объекты — это не кухня ООП. Объекта в них как бы и нет, он лишь подразумевается. Предлагаю на них тоже забить.
S>>Как раз LoD не запрещает такую мега-жесть. Со своими собственными методами все что угодно.
ARK>Не запрещает, но делает бессмысленным (в той трактовке, в какой я его понимаю). Т.к. извне уже нельзя разрушить структуру объекта, все изменения полей идут через его методы, так что городить лапшу из подписки уже не надо — достаточно проконтролировать несколько точек входа в самом объекте.
Любая мегажесть имеет тот смысл, который вкладывает в нее автор. LoD не поощряет и не мешает мегажести. Он лишь запрещает в некоторых случаях вызывать метод через точку.
S>>Мне не кажется что тут. В тот момент, когда мы разрабатываем публичный интерфейс некого объекта, мы уже решаем, какие знания об объекте будут лишними для использования извне. Здесь мы руководствуемся минимальностью, полнотой, непротиворечивостью, стабильностью публичного интерфейса, принципами инкапсуляции (в широком смысле слова как дуализмом абстракции). Уже на этом этапе при удачном проектировании из объекта не должно торчать то, что сделает его клиентов зависимым от деталей реализации объекта.
S>>А LoD как раз безотносителен соображений успешности проектирования интерфейса объекта (и частоты его использования) и относителен лишь того, каким образом был получен объект внутри метода (параметром ли, инстанциирован ли напрямую, взят ли из глобальной переменной, либо иным способом).
ARK>Вот я считаю как раз, что определение (расширенное) должно влиять именно на структуру создаваемого объекта. Как я уже упоминал, именно это подразумевается в литературе и виденных мной обсуждениях в инете.
Да. Если мы у объекта не будем делать инстанс-методы, то применять LoD будет просто не к чему
Но все-таки закон не о том, какие объекты писать, а о том, какие методы не вызывать.
ARK>Появление делегирующих методов в самом объекте местами неизбежно, да. И если их окажется слишком много, то это показатель того, что что-то не так.
ARK>А про временные поля в "Чистом коде" Мартина утверждается, что это хорошо — главное чтобы класс не был большим и не имел много обязанностей.
Вот у Боба как раз более вменяемые критерии чистого кода. В том числе что касается знания о внутренней структуре левых объектов. Например, правило "одного уровня абстракции на функцию".
К сожалению раздел о LoD у того же Боба цитирует определение буквально и не раскрывает сути его работы.
Да, Боб добавляет неразбирихи. Оказывается, что надо делать различие между объектами и структурами данных. Знать лишнее об объектах плохо, а о структурах данных — нет.
