Sem comentários

Terminei o último post dizendo que eu ia falar sobre o que imagino como o futuro (da forma de desenvolvimento) dos sistemas e aplicações. Porém, uma coisa triste aconteceu depois que eu resolvi instalar o BSPlayer para ver o primeiro episódio de Taken, do Spielberg: Blue Screen no Windows!
Passei a madrugada e o dia inteiro tentando recuperar a instalação, mas não teve jeito. Depois de muito suar e uma pilha de backups em DVD, acabei reinstalando o Windows (na verdade, nesse momento, ele tá no meio da instalação ainda - agora to usando o outro note com Linux, o que detesto).
Assim, depois dessa história triste, não vou desperdiçar um assunto tão interessante como o futuro da programação em um post escrito com o coração machucado (...)
Mas pra não deixar você triste, vou recapitular a questão dos agentes e sua implicação no tocante à ligação tardia entre controles, eventos e regras de negócio.
Quando eu disse que existia uma consequência do uso dos agentes em relação ao baixo acoplamento e alta coesão, entende-se que, ao usar agentes para formar a tríade controle-evento-ação, isso se dá de forma que não existem dependências sintáticas no código-fonte do sistema. Em palavras de programador (o que eu gosto), não existem declarações import na classe de bean. Veja isso abaixo:

package a.b.c.d;

public class Cliente {

@Agent("focusLost", "validarDescricaoPessoalDoCliente")
String descricaoPessoal;

}

Nesse pequeno exemplo, a classe bean Cliente possui uma propriedade chamada descricaoPessoal, a qual é mapeada durante a execução do sistema para um controle do tipo caixa de texto (bom, pelo menos esse é o comportamento inicial previsto do Merlin, mas pode mudar...). A esse controle, está ligada à ação validarDescricaoPessoal, a qual é invocada quando ocorrer o evento focusLost do controle, ou seja, quando o foco de trabalho do usuário sair do controle de texto referente à propriedade em questão.
A pergunta que surge aqui é: O que é essa ação? Uma ação nada mais é do que uma regra de negócio e, como tal, está implementada em um método qualquer.
Os métodos que implementam as regras de negócio podem estar em qualquer lugar: dentro do próprio bean, em um EJB, em um WebService ou, pasmem, podem ainda nem existirem fisicamente!
No nosso exemplo simples, a regra de negócio, ops, ação, poderia ser implementada como:

package x.y.w.z;

public class RegrasDeValidacao {

public void "validarDescricaoPessoalDoCliente" {
JTextBox descricaoPessoal = (JTextBox) Merlin.getControl("cliente.descricaoPessoal");
if (descricaoPessoal.getText().indexOf("http://")) {
JOptionPane.showMessageDialog("Você não pode colocar endereços web nesse campo.");
descricaoPessoal.requestFocusInWindo();
}
}
}

Essa regra simplesmente evita que o usuário digite um endereço web dentro do campo de descrição do cliente, exibindo uma mensagem de aviso e colocando o foco no controle novamente.
Percebe-se aqui que a ligação entre o evento focusLost e a regra de negócio validarDescricaoPessoalDoCliente é feita com o uso dos nomes baseados em texto puro, ou seja, Strings. Ao olhar o código da classe Cliente, percebe-se que a mesma não importa o pacote x.y.w.z que contém a regra de negócio. Ela também não importa nenhum pacote java.awt nem javax.swing, que conteriam o evento de foco. De forma análogoa, a classe RegrasDeValidacao não importa o pacote a.b.c.d para ter acesso ao controle da tela a ser renderizado. Na prática, isso significa que, em tempo de compilação, nenhum dos elementos da tríade controle-evento-ação se conhece.
É desse comportamento "aberto" que surge a pergunta: E se o programaodor escrever "ffocusLost" ao invés de "focusLost", ou "validarDescricaoPessoalCliente" ao invés de "validarDescricaoPessoalDoCliente", ou qualquer outro erro simples de digitação? A consequência é que o agente não conseguirá efetuar a ligação entre os elementos da tríade. Como resultado, a regra não será executada.
Bem, isso é extremamente perigoso, pois não temos como validar as se as ligações entre os controles, eventos e regras de negócio estão consistentes. Isso não é um ponto contra, uma vez que, usando a abordagem tradicional do Swing, a coisa fica toda consistida em tempo de projeto, pois as regras estão contidas em classes que implementam interfaces pré-definidas?
A resposta, felizmente é não. Como vou mostrar no próximo post existem meios de fazer essa validação antes do sistema executar.