Design Patterns em formulários Windows complexos – Parte I

Design Patterns em formulários Windows complexos – Parte I

Introdução

A seis anos eu trabalhava com Delphi em projetos de outsourcing. Gostava do trabalho, pois tinha oportunidade de, a cada projeto, conhecer pessoas novas em ramos de atividade quase sempre diferentes. Por outro lado, algo que me incomodava muito era a falta de tempo dedicado a pensar no que era feito. Hoje, quando penso nisso, vejo que o foco era fazer funcionar para cumprir o prazo.

Um dos projetos que mais me recordo desta época é o de um software que seria utilizado para controlar transações financeiras de uma corretora. Esta corretora controlava os investimentos de centenas de clientes. Regras de negócios à parte, o mais interessante deste projeto era o fato de que ele deveria possuir um dashboard que serviria como uma espécie de painel de alertas. Reza a lenda que na especificação original deste painel havia palavras como mediúnico e sagrado. Mas esta especificação eu não vi...

Em última análise este dashboard era um formulário que deveria funcionar como uma espécie de painel de carro, emitindo avisos conforme a situação atual. Eis algumas características que constavam na especificação final:

·         O usuário deve ter a liberdade de ‘montar’ o painel da forma como bem desejar;

·         Adicionar um novo indicador deve ser o mais simples possível (do ponto de vista de programação e do ponto de vista de usabilidade);

·         Ao alterar um parâmetro do painel, os indicadores que forem afetados devem ser atualizados.

Hoje vejo que o mais próximo do ideal seria que nós fizéssemos as partes deste formulário com o mínimo de acoplamento possível umas com as outras. Um indicador não deveria conhecer todas as partes afetadas por uma modificação realizada nele, por exemplo.

Pois bem, isto seria o ideal, mas não foi o que fizemos. Para tornar curta uma história que é longa vou dizer o seguinte: Nós fizemos o programa, levamos cerca de nove meses para construí-lo, ele roda até hoje e atualmente é um exemplo para mim. Um exemplo do que não deve ser feito! O tal formulário do dashboard hoje está com cerca de 30 mil linhas e é um bloco monolítico (eu já vi programas Clipper melhores estruturados). Veja bem, eu estou falando de uma classe com milhares de linhas, centenas de métodos e com centenas de agregações que conhece todos (eu disse todos) os detalhes imagináveis da operação do dashboard.

A situação era tão grave que manter aquele programa era quase como isto:

·         Cliente paciente: Doutor, meu braço dói;

·         Desenvolvedor residente: Deite aqui, por favor. Vou aplicar uma anestesia geral;Cliente paciente: O que?! Eu só estou com dor no braço! Tire a mão de cima de mim...;

·         Desenvolvedor cirurgião: Bisturi, por favor...

Brincadeiras à parte, o que aconteceu naquela ocasião foi que pensamos na interface como algo feito em camadas, não como uma classe. Minha teoria é que com o advento da programação “orientada a eventos” sugerida pelo modelo de desenvolvimento RAD, alguns programadores (como nós na época) “esqueceram” que formulários são classes. Para piorar, neste caso específico o formulário tinha de suportar alterações de uma maneira melhor do que simplesmente sair colocando “if” (e bota if nisto) nas rotinas existentes.  Bem, o “jeito” encontrado para fazer aquilo pode ser resumido da seguinte forma:

1-Colocávamos um monte de painéis no formulário.

2-Conforme a ação que usuário escolhesse, controlávamos as propriedades Visible destes painéis e, às vezes, até de controles dentro deles.

3-Todo mundo conhecia todo mundo. Um indicador sabia quem ele teria de afetar.

4-Voltar ao item 1.

Para tentar mostrar alguns dos problemas que nós enfrentamos com esta abordagem, criei um programa com o objetivo de simular as mesmas situações de interface proporcionadas por um software da Microsoft chamado MS-SQL 2000 BPA. Este software é bem útil para quem utiliza SQL Server e pode ser baixado no seguinte endereço:

http://www.microsoft.com/downloads/details.aspx?FamilyID=b352eb1f-d3ca-44ee-893e-9e07339c1f22

&displaylang=en

MS-SQL BPA: Versão original versus versão cover.

No que tange a interface com o usuário, o software é baseado em páginas que vão sendo apresentadas à medida que o usuário escolhe as opções no painel contido na parte esquerda do formulário. O programa também limita as opções disponíveis conforme o contexto atual.

O código é o mais simples possível:

private void SetActualEnvironment(BpaCoverEnvironment environment)

{

        if (environment == BpaCoverEnvironment.WelcomePage)

        {

               this.panWelcome.Visible = true;

               this.panLogin.Visible = false;

               this.panInstances.Visible = false;

               this.panGroups.Visible = false;

               this.panReports.Visible = false;

               this.llInstances.Enabled = false;

               this.llGroups.Enabled = false;

               this.llReports.Enabled = false;

               this.llLogout.Enabled = false;

        }

        else if (environment == BpaCoverEnvironment.LoginPage)

        {

               this.panWelcome.Visible = false;

               this.panLogin.Visible = true;

               this.panInstances.Visible = false;

               this.panGroups.Visible = false;

               this.panReports.Visible = false;

… (continua)

Do ponto de vista do designer temos a seguinte situação:

Em minha opinião, levando em consideração o que a prática me mostrou, usar uma estratégia destas em algo mais complexo, nos deixa com os seguintes problemas:

• Devido ao forte acoplamento entre as ‘partes’ do formulário, o código fica muito rígido. Imagine que o programa possa apresentar páginas conforme o ramo de atividade do seu cliente. Fazer isto nesta estrutura só é possível tornando a classe maior e mais difícil de manter;
• A estrutura favorece códigos monolíticos e altamente baseados em controles condicionais. Códigos assim são muito difíceis de reutilizar e manter;
• Como não há um conceito de responsabilidade (o formulário é responsável por tudo), os remetentes de uma solicitação acabam tendo de conhecer seus destinatários. Isto só colabora para aumentar ainda mais o acoplamento. Além do mais pode acontecer do remetente A ter de conhecer o destinatário B que por sua vez também deve conhecer o remetente A. O que significa que mesmo criando ‘controles’ para as partes, elas ainda teriam que se conhecer;
• Caso seu programa adicione partes dinamicamente segundo algum critério, (algo que suporte plugins, por exemplo) um código como este colabora muito para tornar tudo um pouco mais complexo. Não há a possibilidade de conhecer a priori o que será carregado e como aquilo que será carregado interage com o restante do formulário (e com outros plugins, porque não?);
• Dependendo da complexidade do que for feito, o formulário pode ficar com um tamanho muito grande para proporcionar o gerenciamento adequado da complexidade;
• Se o formulário for baseado em partes invisíveis, fazer uma alteração de designer pode ser tão bacana quanto uma corrida de cavalos de tróia cuja chegada é a sua casa.