quarta-feira, 4 de julho de 2012

MVC, MOVE e a Histeria dos Engenheiros de Software

Há alguns dias recebi, em um grupo do google que eu participo, uma mensagem que falava sobre um padrão de projeto que foi criado para "corrigir" e estender o padrão MVC. Achei a idéia dos caras muito interessante. O padrão se chama MOVE (Models, Operations, Views and Events) e pode ser detalhado da seguinte forma:


  1. Models encapsulam todo o conhecimento que sua aplicação possui;
  2. Operations encapsulam todas as ações que sua aplicação executa;
  3. Views encapsulam interfaces entre o usuário e a aplicação;
  4. Events encapsulam as mensagens geradas pelos outros componentes, completando o ciclo.


Não vou entrar em detalhes sobre o MOVE nesse post. Caso você queira ler um pouco mais sobre esse padrão, leia o artigo que motivou esse post, que me foi enviado por e-mail: "MVC is dead, it's time to MOVE on". O importante aqui é que quero salientar que esse padrão não faz tanta diferença quanto parece. Os propositores desse padrão acertam em dizer que "o problema com o MVC da forma como é aplicado acaba colocando código demais dentro dos Controllers". No entanto, eu não enxergo como o MOVE pode fazer melhor. Pelo contrário, o MOVE parece ser um mais complexo que o MVC - e é essa afirmação de que ele "simplifica as coisas" que eu irei criticar...


Vamos simplificar as coisas e evitar entrar por demais dentro dos padrões. Tudo o que precisamos para obter uma separação da interface com o usuário dos dados e do processamento dos mesmos em um aplicativo são Visões (Views) e Máquinas de Estado. E isso é tudo o que o MVC faz em sua essência.

Não vou entrar no mérito de discutir particularidades de Máquinas de Estados. Existe muito conteúdo (LMGTFY ou Mealy vs Moore) sobre Máquinas de Moore (produzem saída durante a transição) e Máquinas de Mealy (produzem saída de acordo com o estado atual)!

Então, nós temos uma máquina de estados com transições que são iniciadas por eventos vindos do mundo exterior e um tipo de "superfície" entre esse mundo exterior e a nossa máquina de estados. Essa "superfície" é o que conhecemos como a Visão.

A Visão é uma janela para um estado em uma dada perspectiva. Nem tudo pode ser visível através dessa janela, um estado pode ser oculto em um determinado momento, mas se mover pela superfície irá, eventualmente, expor todos os estados (inclusive os ocultos). Em determinados pontos dessa "superfície" temos sensores (qualquer coisa que você clique, passe o mouse, digite) que disparam eventos quando "tocados" causando uma transição de um estado para outro. E isso é o que a maioria das aplicações MVC atualmente fazem.

A percepção de Controllers sobrecarregados (e assim também as Views) é em essência causado pelo fato de que na verdade os Controllers simplesmente não existem. Por quê? Em parte porque os Controllers possuem partes que são da Máquina de Estados e partes que são elementos da Visão. E se você realmente quiser uma arquitetura limpa baseada em uma estrutura computacional bem conhecida, tudo o que você têm de fazer é aceitar o fato de que você têm uma Máquina de Estados e Visões dessa máquina, e nada mais. Todo o trabalho que o MVC e o MOVE (e tantos outros padrões) fazem é simplesmente sugerir uma organização para esse modelo mais simples. Mas sugerir um modelo não significa que ele será mais simples. Pelo contrário, significa que se está tomando uma determinada linha de organização dentro de todo o escopo da Máquina de Estados + View que, não necessariamente, será mais simples.

A proposta do MOVE nada mais é do que uma reorganização da forma como o MVC organiza as coisas. Ele adiciona idéias melhores que o MVC em alguns aspectos ao mesmo tempo que perde outras por fazer as coisas de forma diferente. Não há simplificação por parte do MOVE. Se quer simplificar mais do que o MVC, que parta para o uso de Visões e Máquinas de Estados!