Does Passive View quebra a Lei de Deméter?

Question

Eu estou tentando entender como usar Passive View corretamente. Parece-me que todos os exemplos que eu olhar sobre Passive View quebra a Lei de Deméter:

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

Então, qual é a melhor aplicação da Passive View?

Answer 1

Em primeiro lugar, a Lei de Demeter, como a maioria das regras de programação, é mais de um princípio ou diretriz e há ocasiões em que o princípio não se aplica. Dito isto, a Lei de Deméter não se aplica realmente a Passive View , porque a razão para a lei não é um problema neste caso.

A Lei de Demeter está tentando evitar a dependência encadeamento tais como:

objectA.objectB.objectC.DoSomething();

Obviamente, se a implementação de objectB muda de usar objectD vez, em seguida, ele vai quebrar a dependência de objectA e causar um erro de compilação. Se levada ao extremo que acabam fazendo a cirurgia shotgun qualquer momento da cadeia é perturbado por uma mudança de implementação.

No caso de Passive Ver

• O apresentador depende de uma interface para a implementação da visão pode mudar, desde que a interface continua a mesma.
• A visão geralmente expõe propriedades como tipos de dados generalizadas, tais como tipos de sistemas e coleções. Isso permite que você faça alterações para a interface do usuário sem afetar o apresentador.
• Para o apresentador o ponto de vista aparece como nada mais do que uma estrutura de dados, um lugar para recuperar e dados de despejo. Desde o ponto de vista é bastante simples, o apresentador não deve mesmo ser capaz de fazer o encadeamento de dependência.

Assim, o exemplo que você deu normalmente seriam implementadas:

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

Enquanto a vista seria algo como:

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

Espero que isso esclarece as coisas um pouco.

Answer 2

Uma implementação melhor seria ter uma API entre o apresentador ea vista. O Presenter iria enviar dados para a sua exibição através de um método único (definido na interface do View). The View iria gerir a nova entrada de acordo com alguma lógica interna.

Portanto, o apresentador não precisa saber nada sobre a Vista ea Lei de Deméter é seguro.

Answer 3

Ok, bem, sim, que faz quebrar a Lei de Demeter, que basicamente diz que a interface para um objeto não deve revelar a implementação do objeto. Mas, em seguida, o segundo dá um monte helluva de sugestões para a implementação também.

Eu acho que é hora de perguntar se você tem a interface de direito em geral. O são estes campos de texto? Quem está colocando-os na vista? a vista não deve estar se perguntando o Modelo de dados, em vez de vice-versa?

Talvez você precisa o padrão Observer -. Do Modelo mantém uma lista de partes e notifica-los interessados, quando seu estado interno muda

---

Ah, que Passive View. não tinha olhado para isso há muito tempo. Basicamente, eu vejo duas partes: uma delas é que, ao fazer o controlador (não o modelo) conduzir todas as atualizações, para (presumo) eficiência ele expõe os métodos de campo específico para atualizar esses campos. Isso viola a Lei de Demeter, que é, afinal, apenas uma "lei" em algum sentido metafórico, como a Lei de Murphy. É geralmente uma boa idéia, no entanto. Neste caso, eu refazer a vista e usá-lo como uma fachada para embrulhar as atualizações para o campo individual.

Você não precisa o padrão Observer, porém, porque agora você tem o Controlador fazendo todas as atualizações. Ele adiciona alguma complexidade e erro propensão ao código geral, porque agora você hve para escrever o controlador para fazer atualizações paralelas.