Пассивный взгляд нарушает закон Деметры? - PullRequest
Новая
       12

Пассивный взгляд нарушает закон Деметры?

3 голосов
/ 26 мая 2009

Я пытаюсь понять, как правильно использовать пассивный просмотр. Мне кажется, что все примеры, на которые я смотрю в пассивном виде, нарушают закон Деметры: 

//In the presenter code
myview.mytextfield.text = "whatever";

Так что же является лучшей реализацией Passive View?

Ответы [ 3 ]

4 голосов
/ 19 июня 2009

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

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

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;
    }

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

1 голос
/ 26 мая 2009

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

Таким образом, докладчик не должен ничего знать о виде, и закон Деметры безопасен.

1 голос
/ 26 мая 2009

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

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

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

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

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

...