Introdução A idéia geral dos modelos de separação do software em camadas é a de dar você a possibilidade de variar as camadas independentemente e isso gerar pouco ou nenhum impacto nas demais.
Para conseguir isso, cada camada é projetada de forma que nenhuma saiba muito sobre o funcionamento interno da outra. A maioria só conhece o protocolo pelo qual vai se comunicar com a camada associada.
Não conhecendo detalhes sobre a implementação das camadas associadas, uma camada comunica-se sem necessitar entender o funcionamento das demais. Por isso o nível de abstração do modelo aumenta e você pode facilmente variar a implementação de cada parte (aplicando reutilização do modelo através da combinação de herança e polimorfismo).
MVC
O Model-View-Controller é um padrão criado inicialmente para ser utilizado no sistema de interface gráfica do SmalltalkTM (Goldberg e Robson, 1983), possuindo as seguintes metas:
- Criar um conjunto de componentes que suporte um processo de desenvolvimento de software de alta interatividade.
- Prover um conjunto de componentes que torne possível para programadores criar facilmente aplicações gráficas portáveis.
Antes do MVC, os projetos de interface com o usuário tendiam a agrupar o comportamento da interface e a lógica do problema no mesmo contexto, digamos numa mesma classe. O MVC separa cada parte numa classe diferente, a fim de aumentar a flexibilidade e a reutilização.
O MVC propõe a separação do modelo de interação com a interface com o usuário em três partes: uma Visão (View), um Modelo (Model) e uma Controladora (Controller). A Visão representa a interface com o usuário, a representação interativa do software. O Modelo representa o domínio da aplicação, a lógica sob a qual a Visão opera, transforma e obtém informações. A Controladora é um mediador entre o Modelo e a Visão, que tem como objetivo controlar a interação entre ambos, esconder os detalhes e diminuir a dependência entre as mesmas.
O funcionamento do modelo se dá da seguinte maneira:
1. O usuário executa alguma ação de entrada na interface, ou melhor, na Visão.
2. A Visão notifica a Controladora para mudar o Modelo de acordo com a ação executada.
3. A Controladora notifica o Modelo sobre a ação.
4. O Modelo recebe a notificação da Controladora, possivelmente alterando seu estado, e notifica indiretamente a todos que necessitam saber que seu estado se alterou.
A notificação indireta é feita registrando-se no Modelo todos os objetos que necessitam saber sobre sua atualização. No entanto, o Modelo não sabe nada a respeito dos objetos que ele notifica, a não ser que eles possuem um método comum para atualização (possivelmente se chamando Atualizar ou outro nome conveniente). Quando o Modelo precisa notificar outros objetos sobre sua mudança ele apenas chama este método, que envia uma mensagem para todos os objetos registrados (broadcast). Assim sendo, os objetos que são notificados de atualizações no Modelo implementam um método comum (Atualizar), e por terem o mesmo comportamento, implementam (herdar de) uma mesma interface.
Quais podem ser os objetos notificados ? Eles podem ser as Controladoras ou mesmo as Visões. (Em breve, possivelmente em outro post, estarei discutindo problemas e melhorias relacionadas, além de outros modelos).
Nota sobre uso de Padrões:
O comportamento acima descrito sobre a notificação de objetos foi catalogado como um Padrão de Projeto (Design Pattern) sobre o nome Observador (Observer). A idéia é que as classes que são notificadas sobre as atualizações são as “observadoras” e as que enviam a notificação são as “observadas”.
Caso você também tenha notado, o papel da classe Controladora do modelo MVC pode ser descrita também como um Padrão, catalogado sob o nome de Mediador (Mediator). No padrão Mediador, um objeto encapsula como um conjunto de objetos interage. Ele promove o acoplamento fraco para evitar que os objetos se refiram explicitamente uns aos outros, permitindo que eles variem independentemente.
Sendo assim, vamos analisar um exemplo simples, para retratar o modelo MVC:
Um usuário deseja conceder desconto em uma venda que ele está realizando. Quando o novo desconto é informado, o total da venda é recalculado e atualizado na tela, refletindo a mudança.
Para isso, teremos uma janela de venda (GUI_Venda) e um classe de venda (Venda).
Venda é uma classe (filha de) Observada e GUI_Venda é (filha de) uma classe Observadora.
Vamos nos ater ao problema proposto:
Ao se conceder um desconto à venda, ela recalcula seu total. É desejado entretanto que ao recalcular seu total, a interface com o usuário exiba o novo total recalculado.
Tomando-se as devidas abstrações, o modelo seria parecido com este:
Ao recalcular seu total (método RecalcularTotal), venda notifica seus observadores (veja diagrama estrutural do padrão Observador), fazendo com que eles se atualizem com o total da venda. Isso acontece sem que Venda saiba quem está se atualizando. Ela sabe apenas que há observadores que serão atualizados.
Essa é a idéia por trás do padrão Observador, e é a base do MVC.
A atualização via notificação indireta é uma poderosa ferramenta para nos auxiliar no desenvolvimento de diferentes interfaces para o mesmo modelo. Isso porque a informação permanece sempre sincronizada com o modelo. Ao alterarmos o modelo, essa alteração se reflete em todas as interfaces.
Em um próximo post estarei discutindo mais sobre o modelo MVC, alguns padrões relacionados e alguns outros modelos, como o Model-View-Presenter (MVP).
Até breve.
