Depois de apresentar esta segunda versão, foi pedido que se mostrassem esferas movimentando-se dentro de um cubo ou de uma esfera maior - o primeiro passo para realizar a simulação do movimento browniano. O código cresceu bastante, e foi necessário introduzir alguma padronização nele (nomes de métodos e identação), para facilitar sua manutenção e seu desenvolvimento.
![]() |
Foi pedido para que as esferas colidissem, inicialmente, apenas com o cubo (ou esfera) - o ambiente de difusão. Isso exigiu a implementação de detecção de colisão simples, onde apenas um dos objetos está em movimento e o ponto de colisão, juntamente com a normal deste ponto, pode ser facilmente calculada.
O resultado destas alterações pode ser visto na Figura .
O resultado da simulação pode ser visto na Figura
.
Neste ponto, o paradigma de orientação a objetos começou a conflitar com o modo
como o glade--
gerava o código. Haviam classes bem definidas para as
``moléculas'' e para o ambiente de difusão, mas estas estavam razoavelmente
acopladas a uma classe pouco coesa e com padrões de código diferentes, que
era a classe da interface. O diagrama de classes do programa pode ser visto
na Figura . Olhando para o diagrama, é possível notar que, além
dos padrões de nomes de classes misturados, a classe
inicio
, cuja
responsabilidade inicial era apenas desenhar a interface, estava ficando pouco
coesa, tendo, também, a responsabilidade de criar os objetos da simulação e
atualizá-los a cada quadro. Esses problemas foram determinantes para a decisão
de não utilizar mais o gerador de código.
![]() |
Outros fatores decisivos para tomar a decisão de não utilizar mais o gerador
de código foram a falta de flexibilidade para mudanças na interface, uma vez que
cada mudança exigia a mesclagem do código anterior com o recém-gerado, a
recomendação de não utilizar o gerador feita pelos próprios desenvolvedores
do GTK e a dificuldade de utilizar as ferramentas de auxílio à compilação
determinadas pelo glade--
no Windows.
Luiz Fernando Oliveira Corte Real 2008-11-28