Refatorando o ModelLocator do Cairngorm – Parte I

Recentemente, estou em contato com um projeto que utiliza a micro-arquitetura Cairngorm e o padrão ModelLocator de uma forma bem responsável. Isso me motivou a escrever esse post e reconsiderar a necessidade do uso do padrão ModelLocator em minhas aplicações Cairngorm, ou pelo menos ter muito mais cuidado ao utilizá-lo.

Geralmente, o que encontramos são implementações monolíticas do ModelLocator no Cairngorm, com centenas de linhas de código para armazenar estados da aplicação, na tentativa insana de centralizar o modelo de dados da aplicação num ponto único, de fácil acesso. Confesso que isso sempre me incomodou, uma vez que torna o ModelLocator um anti-pattern, um repositório de variáveis globais e scripts procedurais (digo, Commands …. rs).

O binding para variáveis globais torna os componentes menos reutilizáveis, dificultando os testes, a substituição do modelo, a modificações das views da aplicação, a divisão de responsabilidade, promovendo assim um forte acoplamento entre as partes, justamente o oposto do que um design pattern deveria fazer: promover reutilização de código, programação orientada à interface, baixo acoplamento, divisão de responsabilidade, etc.

Além do mais, o nome “ModelLocator” sugere que os objetos desse tipo serão utilizados para alocar modelos, ainda mais pelo fato dele implementar o padrão Service Locator. Mas não, no Cairngorm o que encontramos é um Model Locator que na verdade é o próprio modelo.

Outro fato que me incomoda bastante, é o da implementação do ModelLocator no Cairngorm ser vendido como um exemplo do padrão Singleton, uma vez que na verdade é mais um exemplo do padrão Monostate, que pode ser descrito como uma classe com membros estáticos, de forma que todas as instâncias dessa classe compartilham a mesma informação.

Bom, tudo bem, mas agora você deve estar se perguntando: “Como posso resolver esse problema?”. Resposta: Domain Models, Presentation Models e Injeção de Dependência.

Com o uso do padrão Domain Model, podemos atribuir à ele a tarefa de estruturar os dados da nossa aplicação e definir seus comportamentos (lógica de dados), retirando assim essa responsabilidade do ModelLocator. Aqui cabe uma discussão com relação à distribuição de responsabilidades, uma vez que muitos irão consider mais adequado (e talvez o seja mesmo) manter a definição de comportamentos nos Commands.

Um dos papéis do padrão Presentation Model é o de separar a view do model, adicionando um objeto mediador entre eles, tornando tanto a view quanto o modelo substituíveis, isso é, desacoplados. Isso faz com que tudo que a view precise, tanto dados quanto métodos, esteja presente nesse objeto presentation model.

Com a injeção de dependência, o componente não é mais responsável por recuperar uma instância do modelo, ao invés disso a responsabilidade é repassada a outro componente que deseja utilizá-lo.

Por exemplo, ao invés de:

Teríamos:

Isso nos leva a crer que não exista a necessidade do ModelLocator ser um Singleton, mas sim uma interface (talvez com um nome menos confuso…), de forma que não importe qual será sua implementação. Podem assim existir implementações diferentes para desenvolvimento, teste e produção.

Essa arquitetura faz com que o ModelLocator deixe de ser usado como um repositório de dados, e passe finalmente a ser usado como um repositório de modelos, um local onde poderemos encontrar objetos que armazenam dados, através dos Domain Models e Presentation Models.

Steven Webster vem defendendo junto a Adobe Consulting a incorporação do padrão Presentation Model (também conhecido como Application Model) no Cairngorm, uma vez que ele diz estar utilizando esse padrão em seus projetos de grande escala. Embora haja essa “preferência” de Webster, aparentemente a versão 3.0 do Cairngorm ainda não irá adotá-lo.

No próximo post vamos desenvolver uma aplicação Flex utilizando framework Cairngorm, da forma como estamos acostumados a ver. Depois vamos refatorá-la para aplicar os padrões que apresentei a vocês.

Até a próxima, e fiquem a vontade para perguntar!

Veja aqui a segunda parte desse post.

Referências:

Steven Webster comenta sobre a adoção do padrão Presentation Model no Cairngorm 3.0:
http://www.adobeforums.com/webx/.59b654d0

Martin Fowler explicando o padrão Presentation Model:
http://martinfowler.com/eaaDev/PresentationModel.html

Paul Williams explicando o padrão Presentation Model:
http://weblogs.macromedia.com/paulw/archives/2007/09/presentation_pa.html