Нарушает ли пассивный вид Закон Деметры?

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

Закон Деметры пытается предотвратить цепочку зависимостей, например:

objectA.objectB.objectC.DoSomething();

Очевидно, что если реализация objectB изменится, чтобы вместо этого использовать objectD, это нарушит зависимость objectA и вызовет ошибку компиляции. Если дойти до крайности, вам придется делать хирургическую операцию каждый раз, когда цепочка нарушается изменением реализации.

В случае пассивного просмотра

• Презентатор зависит от интерфейса, поэтому реализация представления может меняться, пока интерфейс остается прежним.
• Представление обычно предоставляет свойства как обобщенные типы данных, такие как системные типы и коллекции. Это позволяет вам вносить изменения в пользовательский интерфейс, не затрагивая докладчика.
• Для докладчика представление выглядит не более чем структурой данных, местом для извлечения и вывода данных. Поскольку представление довольно простое, докладчик не должен даже иметь возможность выполнять цепочку зависимостей.

Таким образом, приведенный вами пример обычно реализуется:

//from presenter
view.MeaningfulName = "data";

Хотя вид будет примерно таким:

//from view
public string MeaninfulName
{
    get
    {
        return someControl.text;
    }
    set
    {
        someControl.text = value;
    }

Надеюсь, это немного проясняет ситуацию.

Лучшей реализацией было бы наличие API между Presenter и View. Presenter будет передавать данные в свое представление с помощью одного метода (определенного в интерфейсе представления). Представление будет управлять новым вводом в соответствии с некоторой внутренней логикой.

Поэтому Ведущий ничего не должен знать о Виде и Закон Деметры безопасен.

Ладно, да, это действительно нарушает закон Деметры, который, по сути, гласит, что интерфейс к объекту не должен раскрывать реализацию объекта. Но зато второй тоже дает чертовски много намеков на реализацию.

Думаю, пора спросить, правильный ли у вас интерфейс вообще. Что такое это текстовые поля? Кто устанавливает их в поле зрения? Разве представление не должно запрашивать данные у модели, а не наоборот?

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

Ах, этот пассивный вид. Давно на это не смотрел. По сути, я вижу две части: одна из них заключается в том, что, заставляя Контроллер (а не модель) управлять всеми обновлениями, для (я полагаю) эффективности он предоставляет методы конкретных полей для обновления этих полей. Это действительно нарушает Закон Деметры, который, в конце концов, является всего лишь «законом» в некотором метафорическом смысле, подобно Закону Мерфи. Хотя обычно это хорошая идея. В этом случае я бы переделал представление и использовал его как фасад для переноса обновлений в отдельное поле.

Однако вам не нужен шаблон Observer, потому что теперь у вас есть контроллер, который делает все обновления. Это добавляет некоторую сложность и подверженность ошибкам всему коду, потому что теперь вам нужно написать контроллер для выполнения параллельных обновлений.