Artigos Delphi Técnicas Avançadas de POO com Delphi - Revista ClubeDelphi 140
O uso de Boas Práticas, como a aplicação de Padrões de Projeto, ajuda a criar softwares mais fáceis de manter, modificar e evoluir, reduzindo custos e esforço. A aplicação de técnicas avançadas de POO é útil para tirar o máximo de proveito dos recursos da linguagem ao criar sistemas mais flexíveis e modulares, com baixo acoplamento.
A primeira parte deste artigo vai mostrar como criar objetos de forma correta com o Delphi, usando por exemplo Métodos Estáticos de Fábrica, Singletons e Fábricas, usando tipos levemente acoplados. A seguir, vamos examinar um recurso do Delphi presente desde suas primeiras versões, que também ajuda a criar softwares mais flexíveis e reduz código, facilitando a manutenção, é a técnica de reflexão. Outro tema intimamente relacionado com Boas Práticas, também abordado neste artigo, é a refatoração, que permite modificar a estrutura (forma) interna do aplicativo, seja para melhorar sua legibilidade ou design, mantendo seu comportamento (behavior) externo. Técnicas avançadas de POO também são aplicadas na prática nos estudos de caso deste artigo, como o uso de Interfaces, Abstração, Encapsulamento, Polimorfismo, Delegates e Métodos Anônimos.
Assim como qualquer código, um código orientado a objetos mal escrito é tão ruim quanto um código procedural também mal escrito, talvez até pior. A orientação a objetos vai muito além de simplesmente criar uma classe, declarar suas propriedades, alguns métodos e então utilizar um objeto por todo o sistema. É preciso organizar como esses objetos se comunicam, ter o cuidado para que uma classe não faça mais do que ela precisa fazer, e se as camadas lógicas (camada de apresentação, lógica e acesso a dados) não estão se misturando de forma errada, que crie uma dependência entre elas. Existem técnicas, boa práticas e estudos que podem ser aplicados para garantir a boa qualidade de um sistema que faz uso da orientação a objetos. Podemos citar padrões de projeto, uso de interface, abstrações, métodos anônimos e muito mais. Vamos abordar essas boas práticas com exemplos que facilitam o entendimento.
Métodos Estáticos de Fábrica
Uma boa prática é nunca utilizar diretamente os operadores new (Prism) ou Create (Win32) para criar objetos a partir de suas classes concretas. Isso pode causar um forte acoplamento entre elas, o que diminui o reaproveitamento de código e causa dependência que mais tarde pode ocasionar problemas. Uma saída é considerar o uso de fábricas ou métodos estáticos de fábrica. Um exemplo está mostrado na Listagem 1.
Listagem 1. Método estático de fábrica
program Exemplo1;
// Classe PessoaFisica com atributos simples
PessoaFisica = class
property CPF: string read FCPF write FCPF;
// Fábrica que constrói pessoas físicas
Fabrica = class
class function CriaPessoa: PessoaFisica;
{ Fábrica }
class function Fabrica.CriaPessoa: PessoaFisica;
result := PessoaFisica.Create();
GP: PessoaFisica;
// Uso da fábrica ao invés de chamar create diretamente
GP := Fabrica.CriaPessoa();
GP.Nome := 'Guinther Pauli';
GP.CPF := '123456789-00';
Write(GP.Nome,' - ',GP.CPF);
A aplicação de Console consome uma classe PessoaFisica através de uma fábrica, não possuindo um relacionamento direto de dependência. A fábrica possui um método estático através do uso da palavra reservada class do Delphi, logo ela não precisa ser instanciada. O Create está encapsulado dentro da fábrica, não sendo exposto. Este exemplo pode ser melhorado, aplicando-se uma interface para reduzir ainda mais o acoplamento (isso é feito em outro exemplo adiante).
A palavra reservada "strict" foi introduzida no Delphi 7 Preview Compiler para .NET e está presente no Win32. Ela termina com a amizade entre classes na mesma unit, uma exclusividade do Pascal, onde dadas uma Classe A e B residentes na mesma Unit, podem enxergar seus atributos e métodos privados, violando o encapsulamento.
Uma boa técnica seria esconder a instância do objeto dentro da própria classe, juntamente com o construtor, expondo apenas um método público que devolve esta instância interna. Esta técnica é muitas vezes chamada também de Singleton, que possui várias formas de apresentação, dependendo da linguagem e recursos utilizados. Um exemplo está na Listagem 2.
Listagem 2. Escondendo o construtor e devolvendo uma instância estática
// Classe PessoaSocial com atributos simples
PessoaSocial = class
FBlog: string;
FFacebook: string;
FTwitter: string;
// escondendo o construtor
_INSTANCE: PessoaSocial;
property Blog: string read FBlog write FBlog;
property Facebook: string read FFacebook write FFacebook;
property Twitter: string read FTwitter write FTwitter;
class function GetInstance: PessoaSocial;
GP: PessoaSocial;
{ PessoaSocial }
constructor PessoaSocial.Create;
// sem implementação
class function PessoaSocial.GetInstance: PessoaSocial;
if _INSTANCE = nil then
_INSTANCE := PessoaSocial.Create();
result := _INSTANCE;
GP : PessoaSocial;
// Chamando GetInstance ao invés de Create diretamente
GP := PessoaSocial.GetInstance();
GP.Blog := 'http://gpauli.com';
GP.Facebook := '/guintherpauli';
GP.Twitter := '@guintherpauli';
write(GP.Nome,' - ',GP.Blog,' - ',GP.Facebook,GP.Twitter);
Uma outra técnica bem interessante é criar uma fábrica que devolve múltiplos tipos de objetos de dadas classes concretas que possuem um ancestral comum, de forma que possam se aplicar técnicas como herança, polimorfismo e interfaces. A ideia consiste em solicitar a uma fábrica um tipo genérico passando um indicador de baixo acoplamento para ela ("leve"), por exemplo uma flag ou um integer, ou ainda um enum, que não vão causar problemas de dependência. Internamente, a fábrica faz um teste no que foi solicitado e instancia a classe apropriada, devolvendo um objeto de um tipo concreto em uma referência de um tipo mais abstrato.
Vamos examinar o exemplo da Listagem 3, que representa um pequeno framework para modelar objetos de Meio de Transporte. A classe base abstrata MeioTransporte define o comportamento comum a todos os tipos específicos, que através de herança são definidos como Carro, Aviao e Bus. Um método abstrato polimórfico é definido na classe base (Ligar), sendo sobrescrito (override) nas classes descendentes. Como o objetivo aqui é o estudo de boas práticas, arquitetura e design, não se faz necessário implementar os métodos, apenas declarar. Aqui apenas devolvemos uma string para fins de debug.