Artigos Delphi Técnicas Avançadas de POO com Delphi - Revista ClubeDelphi 140
De que se trata o artigo

O artigo trata de apresentar alguns estudos de caso e em cima deles demonstrar a aplicação de boas práticas de Programação Orientada a Objetos com Delphi, incluindo o uso de Fábricas de Construtores, Design Patterns e Interfaces.


Em que situação o tema é útil

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.

Técnicas Avançadas de POO com Delphi

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;
   
  {$APPTYPE CONSOLE}
   
  {$R *.res}
   
  uses
    System.SysUtils;
   
  type
    // Classe PessoaFisica com atributos simples
    PessoaFisica = class
    strict private
      FNome: string;
      FCPF: string;
    public
      property Nome: string read FNome write FNome;
      property CPF: string read FCPF write FCPF;
    end;
   
     // Fábrica que constrói pessoas físicas
     Fabrica = class
     public
       class function CriaPessoa: PessoaFisica;
     end;
   
  { Fábrica }
   
  class function Fabrica.CriaPessoa: PessoaFisica;
  begin
    result := PessoaFisica.Create();
  end;
   
  var
    GP: PessoaFisica;
  begin
    // 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);
  end.

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).

Nota do DevMan

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.

Singletons

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


  program Exemplo2;
   
  {$APPTYPE CONSOLE}
   
  {$R *.res}
   
  uses
    System.SysUtils;
   
  type
    // Classe PessoaSocial com atributos simples
    PessoaSocial = class
    strict private
      FNome: string;
      FBlog: string;
      FFacebook: string;
      FTwitter: string;
      // escondendo o construtor
      constructor Create();
      class var
        _INSTANCE: PessoaSocial;
     public
       property Nome: string read FNome write FNome;
       property Blog: string read FBlog write FBlog;
       property Facebook: string read FFacebook write FFacebook;
       property Twitter: string read FTwitter write FTwitter;
       // Método estático
       class function GetInstance: PessoaSocial;
    end;
   
  var
    GP: PessoaSocial;
   
  { PessoaSocial }
   
  constructor PessoaSocial.Create;
  begin
    // sem implementação
  end;
   
  class function PessoaSocial.GetInstance: PessoaSocial;
  begin
     if _INSTANCE = nil then
        _INSTANCE := PessoaSocial.Create();
     result := _INSTANCE;
  end;
   
  var
    GP : PessoaSocial;
  begin
    // Chamando GetInstance ao invés de Create diretamente
    GP := PessoaSocial.GetInstance();
    GP.Nome := 'Guinther Pauli';
    GP.Blog := 'http://gpauli.com';
    GP.Facebook := '/guintherpauli';
    GP.Twitter := '@guintherpauli';
    write(GP.Nome,' - ',GP.Blog,' - ',GP.Facebook,GP.Twitter);
  end.

Fábricas

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.

...

Quer ler esse conteúdo completo? Tenha acesso completo