Apostila Java

INTERFACES GRÁFICAS BASEADAS EM BEHAVIOR ISMO (SWING)
mais adiante, na aula sobre threads. Outro detalhe interessante a ser lembrado é o fato de que o modelo
pode ser manipulado por outros sistemas de computador. Ou seja, no exemplo acima aparece um
usuário como agente ativo no sistema, mas a figura do usuário poderia ser substituída por algum
processo automático controlado por software e/ou hardware. Imagine um sistema bancário que aplica
dinheiro automaticamente na poupança a cada vez que o saldo for superior a R$ 1.000,00. O usuário,
correntista, fica mexendo em sua conta bancária sem interagir diretamente com as aplicações
financeiras. O próprio sistema bancário é que detecta o saldo suficiente e dispara um processo de
aplicação bancária ou resgate de aplicação.
Muitas situações são imagináveis, a maioria delas prevista em design patterns, o que dá uma boa noção
sobre a necessidade de um estudo detalhado sobre Design Patterns.
Qual a vantagem de se codificar o modelo, o controle e a visão em classes separadas?
Imagine que você desenvolva um sistema de controle de estoque de uma loja, formado por alguns
formulários de entrada de dados, emissão de relatórios e que tenha também o controle fiscal. Agora
imagine que o governo altere as normas fiscais vigentes no País. Caso você tenha codificado seu
sistema em uma única classe, você terá que alterar os trechos de código relativos ao controle fiscal,
procurando esses trechos entre outros códigos que nada tem a ver com o controle fiscal – como, por
exemplo, aspectos da interface, dos relatórios, etc. Ou então imagine que o gerente de marketing de sua
empresa sugeriu mudar drasticamente o visual do sistema, permitindo aos compradores da loja o acesso
direto à consulta de preços através de uma nova interface que agrega informações com marketing.
Mesmo que você tenha codificado seu sistema em módulos separados, se esses módulos possuem
referências entre eles, ou seja, ponteiros entre as classes, você terá um grande trabalho de reformulação
da interface gráfica e, principalmente, de garantir a consistência do sistema – talvez tenha que refazer
tudo.
Embora um software possa ser modulado através de técnicas convencionais, a presença de referências
entre os módulos impede uma dinâmica eficiente na manutenção desses sistemas. Se você tiver, por
exemplo, uma classe de controle fiscal com um ponteiro para a classe que gera a interface gráfica, e
essa interface gráfica for renomeada ou removida do sistema, será necessário modificar também a classe
de controle fiscal para que o sistema continue consistente. Ou então se você quiser reaproveitar uma boa
interface gráfica em um novo modelo, você terá uma complicada tarefa de verificar todos os ponteiros
entre as duas classes.
O CMV vem justamente propor uma forma modular de atualização de sistemas, onde a modificação de
um aspecto do sistema não interfere nos demais. Por exemplo, em um sistema CMV, podemos ter várias
interfaces gráficas diferentes refletindo os dados de um único modelo, ou então diferentes formas de
controle atuando sobre esse mesmo modelo – por exemplo: a interface dos usuários só permite consulta
enquanto a dos gerentes permite modificação nos valores. Quem faz a comunicação entre os
módulos de um sistema behaviorista não são mais os componentes do software,
diretamente via referências, mas sim a própria máquina virtual que possui suporte a
esse tipo de programação - baseada em eventos chamados de notificações. De fato,
o comportamento de um sistema behaviorista gira em torno do modelo de dados – sempre que algum
formato ou valor for modificado no modelo de dados, o objeto que representa esse modelo notifica a JVM
sobre que tipo de alteração ele sofreu. A máquina virtual, por sua vez, se encarrega de repassar a
notificação a todos os observadores que estão associados a esse modelo. Note que o modelo não sabe
se existem observadores sobre ele e nem o quê esses eventuais observadores fazem com as
notificações recebidas, pois não existe nenhuma referência direta entre o modelo (observável) e os
observadores. A comunicação entre os módulos de um sistema CMV aparece na figura abaixo:
112