Confesso que antes mesmo de aprender Flex eu já queria usar Cairngorm, simplesmente porque os caras que eu admirava usavam ou porque isto era sinônimo de melhores práticas, e eu queria fazer o melhor. E muito me intrigou quando um de meus mentores disse que primeiramente precisa enfrentar os problemas que o Cairngorm se propõe a resolver, e hoje posso dizer que já os dolorosamente enfrentei.
Cairngorm, PureMVC, Mate e Swiz são os mais usados, discutidos e criticados frameworks arquiteturais para Flex, estes provem uma coleção de design patterns, soluções para problemas recorrentes de programação orientada a objetos, que define um problema, implementação, quando aplicar e suas conseqüências. De forma bem sucinta, Jeremy Wischusen escreveu o artigo Choosing a Flex framework, onde compara estes frameworks entre si e o cenário que melhor se encaixa, relacionando prós e contras de cada um.
Podemos dizer que design patters é um conjunto de regras que lhe forçam a implementar soluções conhecidas para problemas recorrentes, a fim de se obter um padrão. Cabe aqui citação direta ao post do Beck Novaes na FlexDev sobre o assunto:
Não há problema algum em dois programadores terem soluções distintas. Isto é, de fato, a regra e não a exceção. Agora, o que acontece quando vemos uma determinada solução e pensamos: “eu jamais faria assim”; “esta solução é tão distinta da minha que não consigo ver sentido algum em fazer deste modo”. Pior, o que acontece quando não entendemos porque aquela solução que jamais imaginaríamos é a melhor? É aqui que entram as Conceptual Constraints.
Conceptual Constraints são conceitos que você mantém na mente e que lhe obrigam a procurar alternativas para resolver um problema, pois você sabe que as soluções que lhe ocorreram num primeiro instante irão violar estes conceitos.
Basicamente, se dois programadores tem em mente as mesmas Conceptual Constraints, ou seja, se eles sabem principalmente as coisas que eles NÃO DEVEM fazer, isto irá permitir que, no mínimo, um entenda a solução do outro – não descarto a hipótese que estes dois programadores cheguem a soluções semelhantes graças ao fato de ambos saberem o que NÃO DEVE ser feito.
Exemplos de Conceptual Constraints do Cairngorm:
- O ModelLocator não deve saber nada do Command nem da View;
- O Command não deve saber nada da View;
- A View não deve saber nada do Command;
- O ModelLocator é possível manter o estado no cliente, mas os dados nele armazenados devem ter um significado semântico. No lugar de preço, nome e descrição, devemos ter um objeto Produto no ModelLocator. Além disto, estes objetos, muitas vezes devem encapsular lógica de negócio – o que possibilita a realização de testes unitários;
- Os Commands são as Worker Classes do Cairngorm, como tal, elas devem prover a funcionalidade de negócios do seu aplicativo e nada impede que o Command tenha apenas um método “execute”.
Aplicar fundamentais design patterns sem adotar um framework arquitetural é correr o risco de inventar a roda. Tenho experimentado Cairngorm e PureMVC, e o que mais me agradada é o primeiro, principalmente porque se baseia em técnicas importantes da arquitetura do Flex, com o DataBinding e Event Driven Programming. Por outro lado, o PureMVC é muito interessante para programadores que possuem ótimo conhecimento em orientação a objetos.
Os benefícios são grandes, mas nunca nos atende completamente, motivo que não deve ser usado para não usar framework algum. Talvez seja muito mais fácil construir uma aplicação orientada a gambiarras (POG), desde que seja o único programador e se lembre depois o que aprontou!
