Padrões de projeto: Aplicando boas práticas para a criação de objetos

O conhecimento sobre padrões de projeto só faz sentido para aqueles que desenvolvem softwares de forma orientada a objetos. Não faz sentido tentar aplicar padrões de projeto se você programa centenas de linhas de código em eventos de um controle de user interface em um formulário Delphi, sem separar responsabilidades. Não faz sentido tentar usar padrões se você usa event-driven programming (programação dirigida ou orientada a eventos).

Se o software feito em Delphi da sua empresa precisa passar por uma evolução, modernização, migração, porém está mal escrito, repleto de bad smells, onde dezenas de programadores já colocaram a mão, e o custo para mantê-lo está saindo caro, talvez a melhor atividade antes de aplicar padrões de projeto seja a refatoração. Aplicar refatorações primitivas, como extrair métodos, classes, superclasses, pode tornar o seu software mais modular, simples de manter e evoluir. A partir daí, o uso de padrões de projeto pode ajudar a melhorar os atributos de qualidade do seu software.

Uma outra atividade, muito interessante, é aplicar padrões de projeto no contexto de refatorações (BOX 1).

Ou seja, nunca se aplica um padrão de forma antecipada, pois não sabe se realmente ele será necessário, causando uma complexidade desnecessária, o que chamamos de excesso de engenharia. Programadores não são videntes. Em contrapartida, nunca aplicar um padrão causa uma escassez de engenharia muito comum em aplicações que seguem o modelo RAD de desenvolvimento, como Delphi (existem programadores que usam Delphi há mais de 15 anos e nunca criaram uma classe). O software já tem 10 anos, está na versão 5, ninguém mais entende como ele funciona, o que foi feito, as pessoas perdem a credibilidade, a motivação, os erros são muitos, uma nova funcionalidade que deveria ser implementada em minutos leva horas ou dias, a correção de um bug gera novos bugs, a rotatividade de membros na equipe de desenvolvimento da empresa está alta, e isso está cada vez pior. Tão ruim que o caos já está generalizado e a empresa decide em algum momento reescrever o software do zero, pois não há mais conserto. Nesse sentido, a prática de aplicar padrões de projeto em código existente, no contexto de uma refatoração, se torna uma atividade bastante atraente.

Padrões de projeto se baseiam fortemente em princípios básicos da programação orientada a objetos, mais especificamente, na herança, abstração, encapsulamento e polimorfismo. Aqui é importante distinguir entre herança de classe da herança de abstrações. As heranças que veremos nos padrões são todas de abstrações, de interfaces, sem implementação. É uma herança de apenas dois níveis, já que criar cadeias muito grandes de hierarquia causa complexidade e dificulta a manutenção. Nesse ponto, uma herança de “caixa preta” se torna mais atraente, como faz o padrão Decorator. Se não há o domínio estes conceitos, principalmente a implementação de classes abstratas por polimorfismo, é recomendado fortemente que faça uma pesquisa e se domine estes fundamentos antes de entrar de cabeça no mundo dos padrões.

Os padrões discutidos neste artigo são apresentados no famoso livro “Design Patterns: Elements of Reusable Object-Oriented Software”, escrito em 1995 por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides [1]. Eles ficaram conhecidos como os padrões GoF (Ganf of Four, ou “gangue dos quatro”), em alusão aos seus autores. Ao todo são 23 padrões de projeto, divididos em três categorias: criacionais, estruturais e comportamentais. Este artigo aborda os principais padrões do grupo criacionais.

Padrões de projeto são largamente utilizados no próprio Delphi. Apesar do Delphi ter sido desenvolvido antes do lançamento do livro (o Delphi foi criado a partir do Borland Pascal for Windows na década de 90, que veio do Turbo Pacal da década de 80), pode-se notar muitos padrões de projeto na própria VCL do Delphi e no IDE. Por exemplo, a VCL inteira não deixa de ser uma grande “fachada” para esconder a complexidade e total deselegância da implementação procedural da API do Windows baseada em ponteiros sem tipo e sem classes. É a mais clara implementação que se pode ter do padrão Facade, assim como o próprio .NET Framework também é. Isso porque esses frameworks encapsulam um subsistema inteiro tornando-o mais fácil de utilizar. Quando olhamos para a parte visual da VCL, como os controles, formulários, botões, panels, e o modelo de componente (TComponent), vemos a implementação clara do padrão Composite (composição). De fato, podemos tratar um formulário como uma composição de outros componentes, enquanto o próprio TForm também é tratado como um TComponent (pois em algum momento herda dele). Um DataSource, ao apontar para um DataSet, usa abstração para esconder um tipo concreto e resolve uma chamada Post de forma polimórfica, a fim de usar uma das n diferentes formas de persistir dados em um banco de dados a partir de dados vindos da tela. Ele esconde uma estratégia para persistir os dados, de fato, você pode trocar um TTable por um TClientDataSet configurados da forma correta e os dados serão gravados no mesmo local. É uma espécie de padrão Strategy. Existem objetos na VCL que podem ser utilizadas uma única vez, como Application, por exemplo, o que poderia caracterizar um Singleton. Quando chamamos um método Post de qualquer implementação de um TDataSet, inúmeros outros métodos polimórficos são chamados em TDataSet mas que só são conhecidos em classes descendentes. Eles só estão em TDataSet para serem chamados de acordo com um determinada ordem, um típico Template Method. E por aí vai, existem dezenas de padrões implementados na VCL (e FireMonkey), comprovando que mesmo na década de 90 a equipe de desenvolvimento da então Borland tinha fortes conhecimentos em orientação a objetos. Essas soluções, não só as utilizadas pela equipe de desenvolvimento da Borland, se tornaram tão claras, que foram documentadas para que pudessem ser reutilizadas em outros projetos, como receitas de bolo prontas. Nascia o livro Padrões de Projeto do GoF.