Como refatorar classes de visão “aninhadas” para evitar chamadas profundas de método?

5

Digamos que eu esteja exibindo um monte de dados ( model ) usando uma classe View para renderização. No entanto, muitos dos dados têm sub-dados ( model s) complicados o suficiente para exigir classes de renderização separadas.

No meu design, uma View classe tem um model que está renderizando e tem muitos filhos Views que exibem os sub-dados. Em alguns casos, A View , embora contenha um modelo, pode não ter nada para renderizar e serve mais como um wrapper para os filhos.

No entanto, se você tiver dados muito complexos e suas subvisualizações tiverem subvisualizações, esse design resultará em chamadas de método profundamente aninhadas. Alguns métodos simplesmente transmitem informações para ver as classes que não podem fazer nada a não ser passá-las para seus filhos. Isso parece ineficiente, então imaginei que poderia haver um padrão ou algo que resolva isso com mais elegância.

    
por Cyril Silverman 14.01.2013 / 07:33
fonte

3 respostas

1

Parece-me que você não está realmente separando o modelo e a visão, estando em uma situação em que essa separação é exatamente o que você precisa.

Se "uma classe View tiver um modelo que está sendo renderizado", então não há realmente nenhuma separação entre eles, você pode criar apenas uma classe para isso. Não estou dizendo que há algo inerentemente errado com isso, por exemplo, a estrutura Spring (Web) MVC tem uma classe ModelAndView que pode conter referências a um modelo (composto) e a uma visualização. Eu só estou pensando que, no seu caso, seria melhor se você externalizasse a relação entre modelo e visão: ter suas classes Model separadas completamente de suas classes View, e então ter algum tipo de gerenciador que decida em qual View é usado para exibir o modelo em um determinado momento.

Em seguida, torne cada um deles tão granular quanto necessário para poder reutilizá-los, ou seja, se você tiver algum modelo e uma determinada maneira de exibi-lo, o que é repetido como parte de várias visualizações (mas ao mesmo tempo O modelo também é necessário para ser exibido de forma diferente em outras visualizações), em seguida, fazer as classes Model e View para cada uma dessas situações e fazer com que um gerente decida com qual visão esse modelo deve ir dependendo do contexto atual (pai, solicitação etc.) .

    
por 14.01.2013 / 16:20
fonte
2

Por um lado, ensinamo-nos a usar padrões de design e técnicas de design de senso comum, das quais emerge o ideal de projetar modelos próximos aos conceituais e, por outro lado, nos preocupamos quando nossos modelos resultantes se tornam profundos. E não devemos estar.

Se, conceitualmente, suas exibições são agregações de outras exibições, não vejo problema com estruturas aninhadas e o modelo de delegação resultante. Não vejo problema em delegar visualizações como parte do cumprimento de seu papel, desde que sua interface seja consistente com seu propósito e fale em um nível consistente de abstração.

Deixe-me reafirmar isso. Se você explicasse sua visão aos colegas, e a explicação melhor descrevesse a visão em termos de outras visões, então é assim que o seu código deveria ser.

Na verdade, as visões que o delegado pode estar simplesmente trabalhando para realizar a Lei de Deméter (não é algo para ser fanático sobre , mas definitivamente algo agradável de reconhecer em seus projetos).

Devo dizer que aplico os princípios acima em meu código da interface do usuário com bons resultados. O tratamento de eventos pode se tornar detalhado, mas você tem EventBus para o resgate.

    
por 29.01.2013 / 04:00
fonte
0

Supondo que você tenha uma linguagem de templates suficiente que permita misturar e combinar seus templates, você deve dividir cada parte relevante do seu modelo em seu próprio template, o qual pode ser usado para fazer uma view composite .

Por exemplo, você pode ter um modelo Book , que, por sua vez, tem dados para Bookmarks , talvez alguns Highlights e talvez PageNotes . Agora, cada um deles deve ter seu próprio modelo, que renderiza o conteúdo de maneira significativa, e isso deve ser obtido apenas com os dados relevantes no modelo.

Por que alguém desejaria adotar essa abordagem? Ele permite que você separe suas preocupações. Seu modelo deve ser usado para organizar seus dados e movê-los do ponto A para o ponto B, e sua visualização deve simplesmente processá-los para consumo.

    
por 14.01.2013 / 13:59
fonte