Padrões comportamentais no MVC

A tríade de classes Modelo, Visão e Controlador (Model-View-Controller) é usada para construir interfaces que irão interagir com usuários. Se observarmos os padrões de projetos, por exemplo, o Observer, o qual está dentro do MVC, eles nos ajudarão a perceber o que queremos dizer com o termo “padrão” e qual a sua real importância e influência no comportamento do sistema.

O MVC é composto por três tipos de objetos. O Modelo é o objeto de aplicação, a Visão é a apresentação na tela e o Controlador é o que define a maneira como a interface do usuário reage com as entradas, também chamadas de interação. Antes do padrão MVC, os projetos de interface para o usuário tendiam a agrupar esses objetos e o MVC na finalidade de proporcionar mais flexibilidade e reutilização desses objetos, propôs a separação dos mesmos.

De modo que, resumidamente, o MVC separa Visão e Modelo pelo estabelecimento de um protocolo do tipo inserção/notificação entre eles. Uma visão deve garantir que a sua aparência reflita o estado do modelo. Sempre que os dados do modelo mudam, o modelo notifica as visões que dependem dele. Em resposta, cada visão tem a oportunidade de atualizar-se. Esta abordagem permite ligar múltiplas visões a um modelo para fornecer diferentes apresentações. Da mesma forma, o desenvolvedor também pode criar novas visões para um modelo sem ter de reescrevê-lo, ou seja, flexível e reutilizável.

Outra característica deste padrão é que as visões podem ser encaixadas. Por exemplo, um painel de controle de botões pode ser implementado como uma visão complexa contendo visões encaixadas composta de botões. A interface do usuário para um objeto pode consistir em visões encaixadas, que podem ser reutilizadas em um depurador. O MVC suporta visões encaixadas com a classe CompositeView, uma subclasse de View. Os objetos de CompositeView funcionam exatamente como o objetos de View; uma visão composta pode ser usada em qualquer lugar que uma visão possa ser consumida, mas ela também contém e administra visões encaixadas.

Novamente, poderíamos pensar nesse projeto como sendo um projeto que nos permite tratar uma visão composta tal como tratamentos de seus componentes. Mas o projeto é aplicável a um problema mais geral, que ocorre sempre que queremos agrupar objetos e tratar o grupo como um objeto individual. Este projeto mais geral é descrito pelo padrão Composite. O padrão permite criar uma hierarquia de classes na qual algumas subclasses definem objetos primitivos.

Além disso, o MVC também permite mudar a maneira como uma visão responde às entradas do usuário sem mudar sua apresentação visual. Por exemplo, o desenvolvedor pode querer mudar a forma de como a aplicação deve responder ao receber uma entrada do teclado, ou fazer com que use uma lista de opções ao invés de teclas de comandos. O MVC encapsula o mecanismo de resposta em um objeto controle (Controller), tornando mais simples a criação de um novo controlador como uma variante de um objeto existente.

O relacionamento View-Controller é um exemplo do padrão Strategy. Este padrão é representado por um algoritmo. Ele é útil quando você quer substituir algoritmo tanto estático como dinamicamente, quando há muitas variantes do algoritmo, ou quando o algoritmo tem estruturas complexas que o programador deseja encapsular. Com isso, podemos perceber a importância dos padrões Observer, Composite e Strategy na arquitetura MVC.

Contudo, será que conhecemos o suficiente desses três padrões de projeto? Pensando nisso que este artigo foi escrito e pretende apresentar de forma detalhada e objetiva usando exemplos práticos de implementação de cada pattern.

O que é Padrão de Projeto?

Padrão de Projeto ou em inglêsDesign Pattern,é uma forma organizada de criar soluções reutilizáveis para os problemas recorrentes do dia a dia de um projetista ou programador.

Vale lembrar que é totalmente possível desenvolver softwares sem utilizar padrões de projetos, e o fato de usar não define um código ou software de qualidade. Padrão de projeto é somente um dos vários detalhes que compõem o desenvolvimento de um software. Usar padrões de projetos é uma escolha que cabe a cada desenvolvedor/time. Existem casos onde as empresas desenvolvem seus próprios padrões e seus frameworks de trabalho e conseguem alcançar resultados tão bons quanto os padrões clássicos.