Object Pascal Programming

Memória Segura Utilizando Instâncias de Interfaces

Mon, 17 Jun 2019 00:00:00 +0100

Você sabe que ao utilizar instâncias de interfaces não é necessário destruir o objeto manualmente, utilizando o método Free.

Isso ocorre por quê instâncias de interfaces possuem uma contagem de referência e, assim, o compilador sabe quando desalocar a instância automaticamente.

Mas e se se ocorrer uma exceção dentro de um método de uma instância, numa composição de instâncias de interfaces, seria seguro não utilizar try-finally para ter a certeza que todos os objetos serão desalocados, atribuindo nil as instâncias?

Photo by Gabriel Gurrola on Unsplash

Introdução

Na semana passada eu recebi um email de um leitor do blog, o Carlos, e ele me questionou sobre ter ou não segurança na desalocação apropriada de memória quando utilizamos instâncias de interfaces.

A dúvida dele é interessante.

Segundo Carlos, utilizar instancias de interfaces seria inseguro em comparação com instâncias de classes, pois “se uma exceção ocorrer dentro de algum método, você não terá a chance de desalocar as variáveis de interfaces como fazemos com o try-finally e instâncias de classes” — ele escreveu.

Então ele me enviou um projeto de teste que “provaria” que instâncias de interfaces poderiam ser inseguras e que não há vantagem em relação às instâncias de classes no quesito desalocação de memória pois, segundo ele, seríamos obrigados a utilizar o try-finally para estarmos “100% seguro”.

O exemplo era um pouco mais complexo do que deveria, então eu o reescrevi e enviei à ele. Ele concordou que ficou mais simples de entender mas, o novo exemplo ainda demonstrava que ele estava certo — ele afirmou — pois ainda haviam os vazamentos de memória no final da execução do programa.

Mas até aquele momento, eu só queria ter uma base de código mais simples para, então, mostrar-lhe uma segunda opinião.

Código

O código original foi reescrito, porém a nova versão contem todos os “problemas” apontados por ele e, consequentemente, a mesma saída no final da execução.

Esse é o código completo:

program Project1;

{$mode delphi}

uses
  SysUtils, Classes;

type
  IFoo = interface
    procedure Execute;
  end;

  IBar = interface
    procedure Execute;
  end;

  TFoo = class(TInterfacedObject, IFoo)
  private
    fBar: IBar;
  public
    constructor Create(const aBar: IBar);
    procedure Execute;
  end;

  TBar = class(TInterfacedObject, IBar)
  public
    procedure Execute;
  end;

{ TFoo }

constructor TFoo.Create(const aBar: IBar);
begin
  inherited Create;
  fBar := aBar;
end;

procedure TFoo.Execute;
begin
  fBar.Execute;
end;

{ TBar }

procedure TBar.Execute;
begin
  raise Exception.Create('exception!!!');
end;

var
  foo: IFoo;
begin
  foo := TFoo.Create(TBar.Create);
  foo.Execute;
end.

É um aplicativo de linha-de-comando.

Crie um novo projeto e não se esqueça de marcar a opção para ver o resultado da memória — se você estiver utilizando Lazarus, marque a opção “Use Heaptrc…” em Project Options, debugging.

O término do programa deverá ser algo parecido com isso:

> project1.exe
An unhandled exception occurred at $004017DA:
Exception: exception!!!
  $004017DA  TBAR__EXECUTE,  line 46 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004017C8  TFOO__EXECUTE,  line 40 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004018D2  main,  line 54 of W:/md/dev/proj/test/ide/projects/project1.lpr

Heap dump by heaptrc unit of W:\md\dev\proj\test\ide\projects\project1.exe
74 memory blocks allocated : 2075/2232
71 memory blocks freed     : 1975/2128
3 unfreed memory blocks : 100
True heap size : 262144 (112 used in System startup)
True free heap : 261600
Should be : 261640
Call trace for block $014D7628 size 64
  $0040A1AC
  $004017FA  TBAR__EXECUTE,  line 47 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004017C8  TFOO__EXECUTE,  line 40 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004018D2  main,  line 54 of W:/md/dev/proj/test/ide/projects/project1.lpr
Call trace for block $014A8D70 size 24
  $0040A1AC
  $004017FA  TBAR__EXECUTE,  line 47 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004017C8  TFOO__EXECUTE,  line 40 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004018D2  main,  line 54 of W:/md/dev/proj/test/ide/projects/project1.lpr
Call trace for block $014A8CF0 size 12
  $004017EE  TBAR__EXECUTE,  line 47 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004017C8  TFOO__EXECUTE,  line 40 of W:/md/dev/proj/test/ide/projects/project1.lpr
  $004018D2  main,  line 54 of W:/md/dev/proj/test/ide/projects/project1.lpr

Não importando as diferenças na finalização do programa entre Lazarus e Delphi, apenas tenha atenção nessa linha:

3 unfreed memory blocks

O código não tem nenhum try-finally e estamos utilizando instâncias de interfaces, como IFoo e IBar, e a saída são 3 blocos de memória não liberados, devido ter ocorrido uma exceção em TBar.Execute. Do contrário, não haveria nenhum vazamento de memória — você pode verificar isso comentando a linha que gera a exceção.

Isso prova que interfaces são inseguras se exceções ocorrem, certo?

Bem, não tão rápido.

Primeiro de tudo, sugiro que você leia o código, linha a linha, e veja se consegue descobrir o que há de errado.

O Diabo Mora nos Detalhes

Para começar, o vazamento de memória acima não tem nada haver com instâncias de interfaces. Na verdade, você pode remover as interfaces completamente, adicionar try-finally para desalocar a memória manualmente e, mesmo assim, a saída do Heaptrc irá continuar a mesma.

Não acredita?

Tente você:

program Project1;

{$mode delphi}

uses
  SysUtils, Classes;

type
  TBar = class;

  TFoo = class
  private
    fBar: TBar;
  public
    constructor Create(const aBar: TBar);
    procedure Execute;
  end;

  TBar = class
  public
    procedure Execute;
  end;

{ TFoo }

constructor TFoo.Create(const aBar: TBar);
begin
  inherited Create;
  fBar := aBar;
end;

procedure TFoo.Execute;
begin
  fBar.Execute;
end;

{ TBar }

procedure TBar.Execute;
begin
  raise Exception.Create('exception!!!');
end;

var
  bar: TBar;
  foo: TFoo;
begin
  bar := TBar.Create;
  foo := TFoo.Create(bar);
  try
    foo.Execute;
  finally
    bar.Free;
    foo.Free;
  end;
end.

Se você compilou e executou essa versão, viu que a saída do programa com o relatório do Heaptrc (ou similar) é praticamente o mesmo.

Os 3 vazamentos de memória continuam, provando que o “problema” não são as interfaces.

Será um problema no compilador?

Solução

Primeiramente, vamos separar o código principal em uma unidade para ser utilizada tanto em uma aplicação Console como GUI.

Assim vou conseguir demostrar um ponto importante, futuramente.

Aqui está o código refatorado, ou seja, apenas as interfaces e classes separadas em uma nova unidade chamada MyClasses.

unit MyClasses;

{$mode delphi}

interface

uses
  SysUtils, Classes;

type
  IFoo = interface
    procedure Execute;
  end;

  IBar = interface
    procedure Execute;
  end;

  TFoo = class(TInterfacedObject, IFoo)
  private
    fBar: IBar;
  public
    constructor Create(const aBar: IBar);
    procedure Execute;
  end;

  TBar = class(TInterfacedObject, IBar)
  public
    procedure Execute;
  end;

implementation

{ TFoo }

constructor TFoo.Create(const aBar: IBar);
begin
  inherited Create;
  fBar := aBar;
end;

procedure TFoo.Execute;
begin
  fBar.Execute;
end;

{ TBar }

procedure TBar.Execute;
begin
  raise Exception.Create('exception!!!');
end;

end.

Agora, crie um novo projeto GUI. Adicione um Form. Depois um botão nesse Form.

Novamente, se você estiver utilizando Lazarus, marque a opção “Use Heaptrc…” em Project Options, debugging.

Adicione MyClasses ao projeto e ao uses do Form.

No click do botão, codifique:

procedure TForm1.Button1Click(Sender: TObject);
var
  foo: IFoo;
begin
  foo := TFoo.Create(TBar.Create);
  foo.Execute;
end;

Ao executar o projeto e clicar no botão, você verá a mensagem de exceção:

Project project1 raised exception class 'Exception' with message: exception!!!
In file 'MyClasses.pas' at line 51

Clique em continuar para ver a verdadeira exceção e depois em OK.

Finalmente, feche o programa.

Se você não esqueceu de marcar o Heaptrc, um ShowMessage será mostrado:

Heap dump by heaptrc unit of W:\md\dev\proj\test\ide\projects\project1.exe
1764 memory blocks allocated : 1804912/1810440
1764 memory blocks freed     : 1804912/1810440
0 unfreed memory blocks : 0
True heap size : 688128 (112 used in System startup)
True free heap : 688016

Nenhum vazamento de memória, utilizando o mesmo código do início do artigo.

O que está acontecendo aqui?

O verdadeiro problema é não capturar a exceção em nenhum lugar do programa.

Mas um programa GUI, por padrão, captura todas as exceções caso o programador não o faça deliberadamente.

E isso faz com que o programa continue em execução “mais ou menos” no ponto onde a exceção foi gerada, ou seja, o programa continua em execução.

E aqui entra uma vantagem das instâncias de interfaces: o compilador adiciona um try-finally implícito para que suas contagens de referência sejam decrementadas.

Sabemos que um try-finally sempre será executado, independentemente de houve uma exceção dentro do seu bloco.

Por isso as instâncias de IFoo e IBar são decrementadas e, consequentemente, destruídas mesmo após ter ocorrido uma exceção.

Vamos voltar ao programa de linha-de-comando.

Crie um novo programa e adicione a unidade MyClasses.

O código é similar ao código do botão, porém é necessário um try-except, pois aplicações console (por padrão) não tem um handle de exceções:

program Project1;

{$mode delphi}

uses
  SysUtils, Classes, MyClasses;

var
  foo: IFoo;
begin
  foo := TFoo.Create(TBar.Create);
  try
    foo.Execute;
  except
    on e: Exception do
       writeln(e.Message);
  end;
end.

Compile e execute.

Veja que não há mais vazamentos de memória.

> project1.exe
exception!!!
Heap dump by heaptrc unit of W:/md/dev/proj/test/ide/projects/project1.exe
72 memory blocks allocated : 1916/2064
72 memory blocks freed     : 1916/2064
0 unfreed memory blocks : 0
True heap size : 196608 (112 used in System startup)
True free heap : 196496

Mesmo sem o try-finally as instâncias de IBar e IFoo foram destruídas automaticamente pelo compilador.

Conclusão

A utilização de instâncias de interface é, de certa forma, mais segura do que instância de classes.

No entanto, se você começar a brincar com ponteiros, cast entre instâncias de classe vs interface, referência circular, etc, sem saber o que está fazendo, será grande a chance de haver vazamentos de memória.

Porém, utilizando o código padrão para instanciar objetos do tipo interface, seu código estará mais seguro contra vazamentos de memória, pois o compilador sempre irá desalocar as instâncias, caso você já as tenha feito atribuindo nil as variáveis.

Até logo.

Classes Mutáveis vs Objetos Imutáveis

Mon, 10 Jun 2019 00:00:00 +0100

É possível ter a comodidade em utilizar classes mutáveis para construir os objetos aos poucos, configurando propriedades e opções de execução além do uso dos construtores, porém com a vantagem de obter instâncias imutáveis no final do processo.

E eu não estou falando do padrão Builder. Aliás você não deveria precisar construir uma classe para criar uma instância de outra classe…

Photo by Djim Loic on Unsplash

Introdução

Os seres na natureza não são criados num único instante.

Um ser dentro do ventre de sua progenitora é “construído” aos poucos, parte por parte.

Imagine todos os órgãos crescendo em um desenvolvimento constante.

Mas mesmo que esse ser ainda não tenha nascido, ele já existe.

Ele ocupa espaço.

Ele interage com o mundo através do corpo de sua mãe…

Porém ele ainda não é uma entidade 100% concluída ou estável.

O mesmo pode acontecer com um objeto no software.

O objeto pode não ter sido totalmente formado, mas ele já existe quando obtemos uma nova instância a partir do construtor de sua classe.

O objeto já existe mas pode não estar pronto para uso.

Faz sentido?

Mutável vs Imutável

Na internet muito tem se falado sobre utilizar objetos imutáveis considerando seus prós e contras.

Eu mesmo sou um defensor de objetos imutáveis.

Porém há casos onde os objetos, apesar de já ter “nascido”, ainda não estão 100% pronto para uso.

Você pode estar pensando: “se podemos ter um objeto mutável, e se isso parece até estar de acordo com a natureza e de como o mundo realmente funciona, por quê eu iria querer ter um objeto imutável afinal?”

Objetos imutáveis são muito mais previsíveis, seguros e simples de usar. Isso é um fato.

No entanto, também haverá casos onde nem todos os objetos em um software poderão ser imutáveis. Vide widgets de formulários Desktop, por exemplo. Os Edits, Memos, Grids… todos são mutáveis.

Apesar da imutabilidade ser o ideal a seguir, ela não é uma verdade absoluta.

Então, se mutabilidade e imutabilidade tem seus prós e contras, e eventualmente iremos trabalhar com ambos, como decidir entre um e outro quando isso já não for pré-determinado?

Eu diria para utilizarmos classes mutáveis em conjunto com objetos imutáveis.

Na Prática

Uma classe é a construtora de seus objetos — a progenitora.

Um objeto deveria ser uma entidade 100% pronta para uso.

Entretanto, assim como uma criatura ainda está sendo formada no ventre, um objeto ainda pode estar sendo construído.

Mas o programador pode determinar quando essa construção termina em um momento especial: quando a instância objeto se transforma em instância de interface.

Se você não tiver nenhum método na interface que promova a mutabilidade do objeto, você poderá construir seus objetos aos poucos utilizando a mutabilidade dos métodos da classe, porém com a vantagem de ter uma instância final imutável que só implementa métodos imutáveis da interface.

É como ter o melhor dos dois mundos.

Imagine uma classe que faz um processamento de Faturas — TInvoiceMaker.

Tal classe necessitaria de uma “configuração especial” sobre como fazer o processamento.

Essa configuração poderia depender de muitos fatores, como período do ano, tipos de contrato, tipos de produtos, promoções, se é apenas um teste ou se está executando em produção.

Estamos apenas especulando as opções.

Primeiro, iniciamos com a definição de uma interface que TInvoiceMaker deverá implementar:

IDataMaker = interface
  procedure Make;
end;

Veja que não há métodos que promovem a mutabilidade, ou seja, não há [Setters].

Uma instância IDataMaker seria passada como argumento para algum objeto/rotina “big process” que recebe um “maker”, não importando quem:

BigProcess(const aMaker: IDataMaker);

Internamente aMaker.Make será chamado.

Modelo Imutável

Então, vamos pensar como poderia ser essa implementação no “modelo imutável”:

TInvoiceMaker = class(TInterfacedObject, IDataMaker)
public
   constructor Create(aPeriod: TPeriod; 
     aContracts: TContractTypes;
     aProducts: TProductTypes;  
     aPromotions: TPromotionArray); reintroduce;
   procedure Make;
end;

O construtor da classe deverá ter todas as dependências injetadas no construtor.

Esse é um modelo sólido. Não há setters. Após o objeto ter sido construído, ele estará 100% pronto para uso.

Esse seria um modelo de implementação ideal.

A classe é pequena; não há muitos argumentos no construtor; fácil de instanciar; imutável.

Agora imagine essa classe seja utilizada em muitos lugares no código e que, na maioria das vezes, seus argumentos serão sempre os mesmos.

Mesmo que haja poucos argumentos no construtor, a repetição deles torna o código verboso e chato para o programador.

Se os contratos são os mesmos, os produtos os mesmos, promoções… por quê não definir valores padrão para tais atributos?

Então implementamos mais um [construtor secundário] que irá chamar o primário:

TInvoiceMaker = class(TInterfacedObject, IDataMaker)
public
   constructor Create(aPeriod: TPeriod; 
     aContracts: TContractTypes;
     aProducts: TProductTypes;
     aPromotions: TPromotionArray); reintroduce; overload;
   constructor Create(aPeriod: TPeriod); overload;
   procedure Make;
end;

O construtor secundário irá passar valores padrão para os argumentos aContracts, aProducts, aPromotions. Apenas o período deverá sempre ser informado, por exemplo.

E, novamente, temos um design limpo e sólido.

Mas sabemos como é a vida de um desenvolvedor: os requisitos mudam; modelos mudam; não há tempo suficiente.

E se, agora, o desenvolvedor precisar informar o período e, também, os contratos? Não há um overload de construtor para informar apenas esses dois parâmetros.

Seguindo o método acima, o desenvolvedor tem duas opções: a) criar um novo construtor ou b) utilizar o construtor principal passando todos os parâmetros — o que eu vejo acontecer bastante em códigos de terceiros onde tais parâmetros são dispostos, por exemplo, assim foo(true, true, '', '', false, '', 1), que é difícil de ler/entender.

Há os argumentos com valores padrão no Pascal. Mas eles não ajudariam muito se quisermos passar apenas 1 dos valores “no meio”. Nesses casos você terá que digitar os valores padrão até chegar na posição do argumento que você deseja informar.

Voltando ao problema, o mais “correto”, seguindo o modelo imutável, seria implementar um novo construtor:

TInvoiceMaker = class(TInterfacedObject, IDataMaker)
public
   constructor Create(aPeriod: TPeriod; 
     aContracts: TContractTypes;
     aProducts: TProductTypes;  
     aPromotions: TPromotionArray); reintroduce; overload;
   constructor Create(aPeriod: TPeriod; 
     aContracts: TContractTypes); overload;
   constructor Create(aPeriod: TPeriod); overload;
   procedure Make;
end;

Infelizmente essa abordagem pode não ser estável no longo prazo, dependendo das mudanças.

Se os argumentos ou a combinação deles aumentarem, teria de haver muitos outros construtores com inúmeras combinações.

Esse é uma abordagem que funciona com classes estáveis com poucas mudanças, não sendo o ideal para classes que tem a tendência de mudar muito.

Modelo Mutável

Então, vamos pensar como poderia ser essa implementação no “modelo mutável”:

TInvoiceMaker = class(TInterfacedObject, IDataMaker)
private
   fPeriod: TPeriod;
   fContracts: TContractTypes;
   fProducts: TProductTypes;
   fPromotions: TPromotionArray;
public
   constructor Create(aPeriod: TPeriod); reintroduce;
   procedure Make;
   property Contracts: TContractTypes 
     read fContracts write fContracts;
   property Products: TProductTypes 
     read fProducts write fProducts;
   property Promotions: TPromotionArray 
     read aPromotions write fPromotions;
end;

A classe tem um construtor primário que solicita o essencial: um período.

Todos os outros atributos que podem ter um valor padrão, poderiam ser implementados como propriedades.

A vantagem é óbvia: não precisamos construir inúmeros construtores com inúmeras combinações. Além disso, podemos adicionar mais propriedades a qualquer momento, com tanto que cada uma tenha um valor padrão que será inicializado no construtor primário.

Esse também é um um modelo limpo e (de certa forma) sólido.

Muitos desenvolvedores acham que a classe deve ter apenas os mesmos métodos que a interface que implementam. Ledo engano.

Há setters através das propriedades, porém cada uma delas terá um valor padrão definido no construtor. Então, o desenvolvedor não é obrigado a passar cada uma das propriedades.

Após o objeto ter sido construído, ele estará 100% pronto para uso.

Mas, como manter a imutabilidade utilizando essa classe?

Na verdade, a instância será virtualmente imutável quando você transformá-la em instância de interface.

Lembre-se que precisamos de uma instância IDataMaker para passar a uma rotina:

/// imutable version
procedure Execute(aPeriod: TPeriod);
var
  maker: IDataMaker;  // interface
begin
  maker := TInvoiceMaker.Create(
    aPeriod, TDefContracts.Create, 
    TDefProducts.Create, []);
  BigProcess(maker);
end;

/// mutable version
procedure Execute(aPeriod: TPeriod);
var
  maker: TInvoiceMaker; // class
begin
  maker := TInvoiceMaker.Create(aPeriod);
  // changing default TDefProducts instance
  maker.Products := TOtherProducts.Create;
  BigProcess(maker);
end;

Você pode ainda utilizar uma construção sem ter que definir uma variável, utilizando WITH and REF:

/// mutable version using WITH
procedure Execute(aPeriod: TPeriod);
begin
  with TInvoiceMaker.Create(aPeriod) do
  begin
    // changing default TDefProducts instance
    Products := TOtherProducts.Create;
    BigProcess(Ref);  // obj.Ref
  end;
end;

Conclusão

A rotina BigProcess só sabe o que é um IDataMaker com apenas o único método Maker. É irrelevante para o processo se aMaker é mutável com propriedades ou totalmente imutável, implementando somente o único método da interface.

Dessa forma você teria classes mutáveis com outras propriedades e métodos gerando instâncias de objetos mutáveis.

Porém, após as instâncias serem convertidas para instâncias de interface, você teria instâncias virtualmente imutáveis, provenientes de classes mutáveis.

Combinar classes mutáveis com objetos imutáveis pode ser uma escolha poderosa no design de sua aplicação, trazendo a flexibilidade da construção de instâncias mutáveis com a segurança das instâncias imutáveis, após serem convertidas.

Até logo.

Implementando Interfaces Utilizando Diferente Assinaturas de Métodos

Mon, 20 May 2019 00:00:00 +0100

Como implementar em uma única classe, duas ou mais interfaces que tenham métodos com o mesmo nome e argumentos?

Talvez o pensamento mais natural à essa pergunta seria: “por quê eu iria querer fazer isso?”.

Se você nunca precisou implementar essa situação antes, pode ser difícil imaginar tal cenário agora. Mas vou lhe mostrar que ele existe e que não é só possível implementá-lo como também é uma ótima técnica para conhecer.

Photo by Raka Rachgo on Unsplash

Estávamos conversando sobre orientação a objetos em um chat privado entre amigos quando uma dúvida pairou no ar.

Não era exatamente uma dúvida, mas mais um desdém sobre como a linguagem C++ consegue implementar herança múltipla sem ser um caos total.

Como a maioria dos desenvolvedores lá utilizam Java, e como essa linguagem implementa herança simples — assim como Object Pascal — não conseguiram visualizar um cenário onde seria possível duas classes terem um método com o mesmo nome e argumentos, enquanto uma terceira classe deveria herdar de ambas.

Nesse momento eu me lembrei de alguns casos de implementação em Object Pascal, onde essa situação é totalmente possível quando implementamos múltiplas interfaces.

Object Pascal não tem herança múltipla como C++, mas podemos implementar mais de uma interface na mesma classe e é bem possível que uma ou mais interfaces tenham nomes e argumentos idênticos.

Como você codificaria esse cenário?

Pelo que eu pude entender lá na discussão, assim como também pesquisando na internet, Java não tem suporte no nível da linguagem para fazer tal construção ou diferenciação de métodos de interface com o mesmo nome e argumentos — e acho incrível ninguém falar sobre isso.

É também interessante que praticamente todas as respostas a essa dúvida, no meio Java, tenham a mesma convicção que poderia ser resumida assim: se duas interfaces tem o mesmo nome, elas não deveriam ter implementação diferenciada nas classes que as implementam.

Eles estão enganados.

Nomes de métodos iguais, mesmo com argumentos iguais, podem exigir implementação diferenciada devido a semântica das interfaces e não devido a assinatura de seus métodos.

Quando estamos definindo uma interface, deveríamos pensar apenas no contrato que ela representa e não como iremos implementá-la em classes mais tarde. Dessa forma, em teoria, não deveríamos nos preocupar se haveria algum conflito de nomenclatura na implementação das classes, pois isso é apenas um detalhe da implementação.

Felizmente, fazer essa diferenciação e implementação utilizando a linguagem Object Pascal não é só possível como também existe uma sintaxe específica para a codificação.

A Embarcadero chama essa sintaxe de Method Resolution Clause.

Agora que você sabe a sintaxe, consegue imaginar cenários para sua utilização?

Vamos enumerar alguns possíveis cenários:

O primeiro cenário está no próprio exemplo da Embarcadero, e mesmo não tendo nada haver com herança múltipla de interfaces, ainda é um necessário válido.

Lá, a explicação é que a interface IMalloc possui os métodos Alloc e Free e precisamos implementá-la na classe TMemoryManager.

Poderíamos implementar um método Alloc — mesma nomenclatura da interface — ao invés do Allocate sugerido no exemplo. E tudo bem.

Mas não poderíamos definir Free — o mesmo da interface — pois esse é um método existente na classe TObject, a classe de onde todas as outras herdam.

O método Free libera o próprio objeto, chamando seu destrutor. Seria esse o objetivo do programador que definiu IMalloc em primeiro lugar, ou seja, desalocar a própria instância?

Se a resposta for sim, então não teríamos problemas pois Free já está implementado em todas as classes. Feito.

Mas se a resposta for não, teríamos que fazer o que a documentação da Embarcadero sugere, definindo um novo método de implementação para implementar o método da interface afim de não chamar o Free padrão de TObject.

Um segundo cenário é sobre reutilização de classes legadas que existiam antes da introdução de alguma interface no código.

Imagine que você tem uma classe que define alguns métodos que implementam mensagens para o usuário em um programa Desktop:

TUserMessages = class
public
  procedure MsgWarning(const aText: string);
  procedure MsgError(const aText: string);
  function MsgQuestion(const aText: string): boolean;
end;

Os métodos MsgWarning e MsgError apenas exibem uma mensagem ao usuário com os respectivos ícones de aviso ou erro. Já o método MsgQuestion retorna true ou false dependendo da escolha do usuário.

Então o sistema evoluiu. Começaram a pensar em introduzir TDD para codificar os testes de regressões. Seria necessário introduzir uma interface para essas interfaces, pois não iriam querer visualizar tais mensagens ao executar os testes automatizados. Seria necessário criar uma classe fake para essas mensagens, implementando uma nova interface:

IUserMessages = interface
  procedure Warning(const aText: string);
  procedure Error(const aText: string);
  function Question(const aText: string): boolean;
end;

Repare que os nomes dos métodos ficaram menos redundantes, pois eles não tem mais o prefixo “Msg” como os da classe original.

Enquanto essa nova interface vai sendo introduzida no código, aos poucos, o que antes estava funcionando deve continuar assim. Isso significa que várias partes do código ainda continuarão utilizando a classe TUserMessages original até a completa refatoração.

Isso quer dizer que não podemos utilizar a classe original para implementar a nova interface fazendo, assim, que essa classe possa trabalhar tanto no código “antigo” como também no “novo”?

Claro que podemos:

TUserMessages = class(TInterfacedObject, IUserMessages)
private
  procedure IUserMessages.Warning = MsgWarning;
  procedure IUserMessages.Error = MsgError;
  function IUserMessages.Question = MsgQuestion;
public
  procedure MsgWarning(const aText: string);
  procedure MsgError(const aText: string);
  function MsgQuestion(const aText: string): boolean;
end;

Dessa forma TUserMessages pode continuar a ser utilizada para construir instâncias da classe e continuar utilizando os métodos (antigos) com prefixo “Msg”, assim como pode ser utilizada no novo código como uma instância da interface IUserMessages.

Um terceiro cenário é sobre a implementação de múltiplas interfaces.

A sintaxe para fazer isso você, agora, já sabe. Mas talvez ainda possa lhe faltar a imaginação onde esse cenário seria adequado ou mesmo requerido.

Por quê, você diria, eu iria querer implementar 2 ou mais interfaces utilizando diferentes assinaturas de métodos?

A resposta irá depender da sutil diferença semântica das interfaces que serão implementadas.

Imagine que tenhamos que criar 2 interfaces que são similares, porém diferentes. Uma interface irá representar um Avião (IPlane) e outra um Planador (IGlider).

Eu não entendo tanto assim de aviação, porém podemos enumerar algumas diferenças entre ambos:

o avião tem motor; o planador não;
o avião é muito mais pesado que o planador;
o avião pode levantar voo por ele mesmo; o planador precisa de outro avião para rebocá-lo ao ar;

Agora imagine que uma empresa revolucionária acaba de lançar uma máquina que pode ser utilizada tanto como um avião como um planador.

Incrível? Nem tanto, eu acho.

Esses híbridos nascem o tempo todo: carros elétricos mas que também utilizam combustível fóssil; carros que andam na terra, mas num clique de um botão viram uma espécie de lancha para andar na água; até mesmo um carro/helicóptero já foi inventado; skates com motor a combustão ou elétrico; bicicletas elétricas, mas você pode continuar pedalando; etc.

Na minha imaginação, essa nova máquina — será que já existe? — teria alguns requisitos básicos:

ser feita de fibra de carbono para ser o mais leve e resistente possível;
possibilidade de acoplar um motor plug-n-play para se transformar num avião;
ter configurações diferentes para o “modo avião” vs “modo planador”;
no modo avião, levantar voo sozinha sendo auto-propulsionada;

Pensando no código, vamos retornar as interfaces e defini-las:

IPlane = interface
  procedure Fly;
end;

IGlider = interface
  procedure Fly;
end;

É isso. Não vamos complicar. São duas interfaces com apenas um método. Ambos são idênticos, ou seja, mesma assinatura.

Nosso novo, incrível e imaginável veículo, representado por uma classe, deveria implementar o método Fly() apenas uma única vez?

Minha resposta é sonoro não. Mas se você continua achando que sim, como uma única classe iria implementar os dois modos de voos tão distintos?

Como explicado acima, o veículo pode ser tanto um avião como um planador. O usuário pode ou não utilizar um motor e, assim sendo, utilizar configurações de voo completamente diferentes.

Apesar do avião e do planador voarem, ambos fazem de maneira completamente diferentes, ou seja, com implementações diferentes.

Precisamos de um nome para esse incrível veículo. Então sugiro batizar essa invenção de “OnePlane”.

Então teríamos a implementação da classe:

TOnePlane = class(TInterfacedObject, IPlane, IGlider)
private
  // real flying implementation methods
  procedure FlyAsPlane;
  procedure FlyAsGlider;
  // method resolution clause
  procedure IPlane.Fly = FlyAsPlane;
  procedure IGlider.Fly = FlyAsGlider;
public
  // will initialize the instance as a plane or glider
  constructor Create(asPlane: boolean = true); reintroduce;
end;

A classe acima exemplifica como implementar 2 métodos idênticos de interfaces distintas em uma mesma classe utilizando implementações completamente diferentes.

A sintaxe é tão simples e explícita que até mesmo desenvolvedores de outras linguagens, como Java, poderão entender essa implementação sem problemas, eu acredito.

Apesar da linguagem Object Pascal ter outra sintaxe ainda mais limpa para implementar mais de uma interface em uma mesma classe, ainda assim esse código parece perfeitamente razoável pra mim. Iniciaríamos a implementação utilizando métodos privados que depois poderiam ser convertido em novas classes, se necessário.

Finalmente, essa sintaxe não é novidade no Free Pascal nem no Delphi. Acredito que ela foi implementada quando surgiram as interfaces. Mas tenho certeza que você poderá utilizá-la perfeitamente na versão Delphi 7 de 2002 em diante, como eu continuo utilizando em vários projetos até hoje.

Até logo.

Usando Paths ao invés de Diretivas de Compilação

Mon, 15 Apr 2019 00:00:00 +0100

Já pensou em utilizar paths, ao invés de diretivas de compilação, para compilar seu projeto em diferentes plataformas?

Photo by Nathan Dumlao on Unsplash

Em meados de 2017 eu escrevi um artigo sobre Diretivas de Compilação, explicando como poderíamos encapsulá-las para ajudar a tornar o código multiplatform.

Basicamente teríamos uma unidade comum a todas as plataformas (FPC e Delphi) e outra(s) unidade(s) específica(s) para cada uma delas.

Por exemplo: uma unidade FooFuncs seria a principal enquanto FooFuncsFPC e FooFuncsDelphi seriam as especializadas.

A unidade FooFuncs utilizaria as unidades especializadas e seus identificadores—interfaces e classes—seriam redefinidos utilizando uma nomenclatura mais genérica para toda a lib ou projeto e sem dependências com qualquer plataforma.

Após quase 2 anos, eu mudei esse conceito para um modelo que considero ainda mais simples e sem utilizar diretivas de compilação: utilização de apenas paths para cada plataforma.

* * *

Veja o projeto Xavier lib, por exemplo.

Dentro do diretório xavier/src/ podemos ver dois subdiretórios: fpc e delphi.

Cada diretório possui 1 unidade com o mesmo nome: XavierCorePlatform.

Sabemos que um projeto não pode ter unidades duplicadas, então como isso funciona?

Basta aplicar o path por plataforma, ou seja, apenas 1 unidade será utilizada por projeto. Se você está utilizando o Delphi, irá utilizar apenas o path src\delphi, por exemplo.

E é só isso.

As vantagens são visíveis em relação a abordagem anterior que utilizava diretivas:

sem necessidade de diretivas de compilação
não é necessário redeclarar identificadores de unidades especializadas
não é necessário haver uma unidade genérica—ex: FooFuncs
basta 1 unidade por plataforma
menos código

No entanto, você poderia considerar a (possível) duplicação de código como uma desvantagem, visto que haverá implementações de classes, com o mesmo nome, em unidades por plataforma. No projeto Xavier, por exemplo, vemos que há algumas linhas muito similares… mas isso não é um problema real.

A implementação por plataforma pode ser muito diferente uma da outra. Existir algumas linhas similares—ou mesmo iguais—é um preço mínimo a se pagar, na minha humilde opinião.

Finalmente, repare que todo código comum entre as plataformas devem estar em outras unidades compartilhadas. No caso do Xavier, tais códigos compartilhados estão nas unidades XavierCore e XavierAdapters. Ambas são utilizadas pelas unidades XavierCorePlatform referente a cada plataforma.

Até logo.

Trabalhando com Exceções em Requisições HTTP

Mon, 01 Apr 2019 00:00:00 +0100

Em requisições HTTP, devemos levantar uma exceção quando recebermos, por exemplo, um código 500?

Photo by Nathan Dumlao on Unsplash

Tivemos uma discussão em um grupo do Telegram sobre utilizar ou não exceções em requisições HTTP, o que me inspirou a escrever esse artigo.

Como todos sabemos, o protocolo HTTP é baseado em texto simples.

Cada requisição do cliente é composto por um cabeçalho e um corpo (opcional):

GET /index.html HTTP/1.1
Host: www.example.com

A resposta do servidor segue o mesmo protocolo, contendo um cabeçalho e um corpo (também opcional) de resposta:

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

A beleza desse protocolo é que mesmo seres humanos, não apenas máquinas, podem ler entender (a maioria do) seu conteúdo.

Então podemos perceber que há um padrão em ambas as mensagens acima, identificado na primeira linha, indicando o sucesso ou erro da requisição ou resposta.

O padrão é determinado por um par de código e texto no qual identificaremos por status.

No exemplo acima, o status é determinado pelo código 200 e o texto “OK”. Mostrando uma resposta padrão de sucesso.

Há uma grande lista de códigos pré-determinados e toda aplicação deveria respeitá-los em todas as requisições e respostas.

Agora, repare que não existem objetos e tão pouco objetos de exceções.

No início do artigo eu disse que a dúvida que gerou a discussão foi utilizar ou não exceções, ou seja, objetos Exception e derivados em clientes HTTP.

Minha resposta?

Você não deveria utilizar exceções em clientes HTTP, somente nas suas classes de negócio.

Se o protocolo não tem exceções, por quê implementá-lo na classe mais básica, ou seja, a que faz a ponte entre o seu sistema e a requisição HTTP?

Para mim, não faz sentido.

É verdade que existem vários frameworks que implementam clientes HTTP como, por exemplo, Indy, Synapse ou até mesmo os clientes padrão da linguagem.

Talvez esses clientes podem gerar uma exceção quando recebem um código 500 ou talvez não. Não importa. Você deveria encapsular essas classes de terceiros em suas próprias classes de acesso HTTP. Assim, você poderia mudar de framework apenas alterando essas classes.

Pense apenas em um cliente HTTP genérico, cru, que implementa o protocolo como ele deve ser: envio e recebimento de mensagens no formato texto. A partir dele você constrói classes de negócio que utilizam o cliente, adicionando comportamento referente as regras de negócio.

Na parte final da série “Microservices com Delphi” você poderá ver mais um exemplo de como fazer o tratamento de códigos de retorno do cliente HTTP. Esse é apenas mais um exemplo e não um padrão. Tudo irá depender da sua aplicação, quais códigos verificar e o que fazer quando recebê-los.

Apenas mantenha os clientes o mais simples possível.

Até logo.

Tipo object Continua Vivo

Mon, 18 Mar 2019 00:00:00 +0100

Existe uma estrutura no Object Pascal que foi o precursor das classes.

Você conhece o tipo object?

Photo by Namroud Gorguis on Unsplash

Em um artigo anterior eu expliquei com dividir o código de um formulário em diferentes objetos, organizando os widgets em diferentes classes para dividir as responsabilidades em diferentes objetos.

Separar partes do código em classes distintas melhoram a legibilidade e manutenção do código. Mas você pode implementar o mesmo conceito sem utilizar classes.

Muitas vezes eu utilizo o tipo object como um helper para um widget ou conjunto deles.

De fato, essa técnica pode ser utilizada não só na implementação de formulários, mas em qualquer parte do código.

Não confunda com os tipos Helpers que adiciona comportamento a tipos já existentes. Existe uma sintaxe especial para declara-los, estendendo outros tipos sem utilizar herança… mas não é deles que estou falando.

Se você não gosta de nomenclatura helper, poderíamos chamá-los de ferramentas, pois eles não representam uma entidade e não implementam uma interface. São apenas ferramentas que serão utilizadas pelos verdadeiros objetos.

Não representar uma entidade é um bom motivo para utilizar o tipo object, mas há outras vantagens.

Performance, por utilizar o stack ou invés do heap na alocação de memória.

Utiliza menos memória, pois são estruturas mais simples, comparadas às classes.

Uso de herança é possível.

Determinar um escopo para um conjunto de funções utilitárias, genéricas e reutilizáveis, ao invés de declarar funções e procedimentos diretamente no escopo da unit.

Simplicidade, sempre será um ótimo motivo para tomar decisões na arquitetura. Por exemplo: não é necessário o uso de try..finally, tornando o código menos verboso.

Uma desvantagem, entretanto, é não existir um [construtor] e por isso não tem como garantir uma inicialização adequada dos campos privados. Diferentemente de uma classe, onde é obrigatório o uso de seu construtor, um tipo object pode ser utilizado diretamente como qualquer outra variável primitiva.

Além disso, a Embarcadero descontinuou o uso do tipo object desde o Delphi 2010, sugerindo o uso de “records com métodos” em seu lugar—uma decisão equivocada, na minha opinião, e não estou sozinho nesse pensamento. Além de perder a compatibilidade com o código legado, introduzir métodos em records é, no mínimo, duvidoso.

Já tínhamos o tipo object e ninguém solicitou pela sua descontinuidade, por quê não mantê-lo?

E para aqueles que não conhecem a sintaxe do seu uso, aqui está um simples exemplo:

type
  TMsg = object
    procedure Show(const aText: string);
  end;
{...}
var
  msg: TMsg;
begin
  msg.Show;
end;

Simples, direto, sem try..finally.

Felizmente o tipo object continua vivo no Free Pascal.

Até logo.

Array de Objetos

Mon, 11 Mar 2019 00:00:00 +0100

Quando você precisa de uma simples lista de objetos, qual estrutura você utiliza?

Photo by Antonio Garcia on Unsplash

Introdução

Todo sistema utiliza listas para armazenar desde valores primitivos até instancias de objetos.

Aqui eu sempre advoguei sobre utilizar objetos em (quase) todos os lugares. Mas temos que ser eficientes e não desperdiçar recursos. Não devemos criar estruturas mais complexas, como classes e interfaces, quando outra estrutura pode resolver o problema, além de simplificar a solução.

Basicamente uma lista pode ser representada por um array, um objeto genérico (ex: TList) ou um objeto especializado que possui regras de negócio que irão trabalhar com os elementos de acordo com requisitos específicos do usuário.

Se você não precisa de uma lista com regras de negócio, arrays podem ser um boa escolha.

Array vs Lista

Poderíamos utilizar lista de objetos em todos os lugares, mas os arrays continuam relevantes.

Arrays armazenam informações no stack, enquanto Listas utilizam o heap.

A utilização do stack tem muito mais performance pois o acesso a esse tipo de memória é muito mais rápido. A alocação da memória é determinada já na compilação do programa, tornando fácil o seu gerenciamento.

O stack é protegido e mais rápido, pois é mais fácil para o compilador alocar/desalocar memória lá. Entretanto, ele é mais limitado quanto ao espaço, comparado ao heap. O heap é “ilimitado” (pode ocupar toda a memória RAM), porém mais lento. Sendo o heap compartilhado por toda a aplicação, é mais difícil/custoso para o compilador alocar/desalocar a memória. E, sendo esses dados “globais” à aplicação, eles muitas vezes devem ser sincronizados quando os acessamos utilizando multi-threading.

Então, como escolher entre eles?

Podemos definir 3 tópicos básicos que você deverá levar em conta, quando for tomar sua decisão: Performance, Regras de Negócio e Transferência de Dados.

Performance

Você usa o stack quando souber a quantidade de dados à alocar na memória já em tempo de compilação. No entanto, não deve ser uma massa muito grande de dados—mesmo havendo configurações/diretivas em cada compilador para customização—ou você poderá obter um erro de memória em tempo de execução.

O heap é utilizado quando você não souber, exatamente, quantos dados irá precisar em tempo de execução ou se houver a tendência de que será uma massa muito grande de dados.

O stack sempre será mais rápido que o heap. Então, se você necessitar da máxima performance, tenha isso em mente quando tiver instanciando novas listas de objetos.

Regras de Negócio

Imagine um sistema de estacionamento de veículos. Se você tem uma classe que representa o estacionamento, então você tem uma lista especializada para armazenar as vagas e carros ou ao menos uma lista genérica dentro da classe especializada.

Você teria regras de negócios referente ao estacionamento como: horário de entrada/saída, número da vagas, serviço de manobrista, etc. Não vem ao caso pensar em todas as regras de negócio de um estacionamento. O mais importante é sabermos que haveria regras de negócio para essa lista especializada, o estacionamento.

Apesar da maioria dos estacionamentos terem um número limitado de vagas, virtualmente pode-se adicionar mais carros em “vagas não-oficiais”, deixando um total de vagas “em aberto”—se isso não acontece na sua cidade/país, bem, apenas considere a possibilidade.

Se o número de vagas é bem grande ou incerto, a melhor opção de escolha nesse caso seria uma lista especializada, alocada no heap, com outros métodos adicionais que implementam as regras de negócio.

Transferência de Dados

Se sua lista existe apenas para armazenar temporariamente objetos ou para passagem de parâmetro entre contextos, por exemplo, um simples array poderia ser utilizado.

Chamo de transferência de dados, pois você poderá transferir desde elementos simples e primitivos até objetos complexos de listas especializadas, entre contextos distintos. Esse seria o meio-termo entre performance vs especialização. Você pode ter listas de objetos, carregando instâncias de objetos complexos, mas utilizar os arrays para transportar apenas parte desses objetos de forma eficiente.

Exemplo. A sua lista de vagas acima, o estacionamento, possui um número X de vagas em uso em um determinado momento. Cada vaga pode ser representada por uma instância. Imagine que o usuário selecionou 3 vagas para “deixar livre”. Após a seleção, é necessário fazer algumas operações com essas instâncias (vagas). Essas operações irão receber um “array de vagas” como parâmetro.

O array seria utilizado por quê você já sabe a quantidade de elementos que ele iria ter—determinado pela seleção do usuário. Criar uma nova lista de vagas (do tipo estacionamento) para adicionar apenas 3 instâncias e então passar como parâmetro seria um desperdício de processamento, além de não fazer muito sentido passar “todo um estacionamento”—uma instância da mesma classe—ou uma cópia da lista oficial com menos registros, apenas para fazer o processamento da liberação das vagas.

Um array seria a escolha mais simples. No entanto, não há só um tipo de array.

Utilizando Arrays Dinâmicos

Existem alguns tipos de arrays como estáticos, constantes, dinâmicos, multi-dimensionais, etc.

Para esse artigo, iremos utilizar os arrays dinâmicos.

Utilizar arrays dinâmicos no Object Pascal é relativamente fácil, porém temos que prestar atenção em duas regras principais:

O índice do primeiro elemento sempre será 0 (zero);
É necessário determinar o tamanho do array antes de inserir seus elementos;

O índice do primeiro elemento sempre será zero, diferentemente de arrays contantes, por exemplo, onde você pode informar outro valor para o primeiro elemento. Tenha sempre isso em mente quando utilizar o array em loops.

O tamanho de um array é determinado pela função SetLength(array, size) padrão.

Abaixo um exemplo do uso da função e a carga de um array of Integer com valores:

var
  a: array of Integer;
begin
  SetLength(a, 10); // from 0 to 9 positions
  for i := 0 to 10 do
    a[i] := i;
end;

Diferentemente de classes e interfaces, para definir um array para armazenar elementos de um determinado tipo, basta apenas uma linha de código, como visto acima.

Foi definido um array para Integer, mas a mesma sintaxe vale para tipos de classes ou interfaces. Se estivermos trabalhando com Vagas—instâncias da interface ISpot, por exemplo—poderíamos definir um array dessa forma:

type
  TSpotArray = array of ISpot;

Não precisamos nos preocupar com herança, métodos ou sobrescrita de métodos, caso estivéssemos definindo uma nova classe.

Apenas uma única linha define um novo container dinâmico de instâncias de ISpot.

Utilizando uma variação do algoritmo acima, você é capaz de inicializar o array e adicionar os 3 itens que o usuário selecionou, passando-o como um parâmetro para o algoritmo que irá desalocar as vagas.

Não há necessidade de se preocupar com o desalocamento de memória, pois tudo será feito automaticamente pelo compilador.

Conclusão

Arrays são ótimas opções para trabalhar com objetos em memória e passagem de dados entre contextos.

Eles são simples, gerenciados pelo compilador no stack e muito mais rápidos que listas de objetos.

Até logo.

Variáveis Locais Deveriam ter Nomes Curtos

Mon, 07 Jan 2019 00:00:00 +0000

Já pensou que você pode estar dificultando a leitura do seu código por utilizar nomes mais longos e verbosos em variáveis locais do que utilizando nomes mais curtos?

Photo by chuttersnap on Unsplash

Nomenclatura é quase uma arte, especialmente no desenvolvimento de software.

Escolher bons nomes irá deixar seu código mais legível e isso será imprescindível para a manutenção do mesmo no longo prazo.

Entretanto, um bom nome não quer dizer um nome mais longo e verboso.

Um bom nome irá depender de alguns fatores. Por exemplo: se o nome identificar uma variável de índice para um loop, a maioria dos programadores irá utilizar “i”.

Por quê “i” e não “index”, já que este último é mais explícito?

É claro que haverá todo tipo e código, todo tipo de nomenclatura. Mas, me refiro a maioria. E a maioria utiliza “i” para a nomenclatura de variáveis de índices.

E se quisermos nos referir a uma posição na tela? Eu diria que a nomenclatura mais utiliza é “x,y”. Podemos declarar um record ou classe como TPoint mas é bem provável que seus atributos sejam X e Y.

“Convenção” — você diria.

Sim, convenção, porém eu acho que o motivo está além disso.

Trata-se de legibilidade.

Quando estamos trabalhando em um contexto bem menor, como a implementação de um método por exemplo, não precisamos de nomes longos e verbosos. Sabemos o que X e Y significam; sabemos que “i” é o índice de um loop; sabemos que “s1” e “s2” (provavelmente) significam strings 1 e 2, respectivamente.

Não me entenda mal. Não estou dizendo que todas as variáveis locais devem ter apenas uma ou duas letras. Depende. E talvez não haja uma regra para determinar qual nomenclatura mais adequada, uma regra que abrange todos os casos possíveis. Mas podemos utilizar o bom senso.

Sugiro que os nomes sejam os menores possíveis, porém sem haver ambiguidades. Por exemplo: seria estranho haver duas variáveis assim:

var
  s1: string;      
  s2: TStream;

São dois tipos completamente diferentes, porém utilizando a mesma nomenclatura. É ambíguo e confuso. Por quê s2 representa o TStream e não s1? Falta lógica.

Porém ainda assim, na minha opinião, ainda seriam melhores que isso:

var
  ClientNameTrimed: string;      
  ClientReturnedAsStream: TStream;

O motivo é simples: se você está nomeando suas variáveis de forma tão longa, é por quê o método está fazendo coisas demais e você precisa identificar cada variável — talvez existam mais de cinco — como única para tentar melhorar a legibilidade do método, mas ignorando os indícios de que o método deveria ser refatorado (dividido) em partes menores. Métodos menores poderiam ter menos variáveis, com nomenclatura mais simples.

Seguindo o primeiro exemplo, podemos refatorar as variáveis:

var
  str: string;      
  stm: TStream;

Apesar de ainda haver certa ambiguidade — str ainda poderia ser considerada uma abreviação de TStream — a legibilidade é melhor. Poderíamos simplificar, refatorando str para apenas s já que trata-se de um tipo primitivo, aplicando a lógica de que “tipos primitivos estão abaixo de classes” e, portanto, utilizam menos caracteres…

O importante é haver alguma lógica de nomenclatura entre a equipe.

Outro exemplo de nomenclatura interessante é dar nomes próprios às variáveis, quando estas são do tipo interface ou classe. Vejamos:

var
  bob: TStream;      
  john: TStream;

Temos 2 streams e, ao invés de nomear como stm1 e stm2 ou algo parecido, apenas damos nomes próprios e curtos, de fácil memorização.

Uma vez que seu cérebro já sabe que bob contém a entrada de dados (apenas um exemplo) e john irá conter a saída processada, seria mais difícil esquecer dos nomes comparado a stm1 e stm2.

Mantenha os nomes de variáveis locais o mais curto possível.

Essa é a minha sugestão.

Até logo.

Como Dividir e Organizar o Código em Formulários com Muitos Widgets

Mon, 17 Dec 2018 00:00:00 +0000

Definir dezenas de métodos em formulários e DataModules parece ser comum entre programadores. Podemos fazer algo para minimizar essa prática?

Photo by Robert Bye on Unsplash

Introdução

Em um formulário com muitos widgets, haveria dezenas de métodos para controlá-los. Esses métodos lidariam com o estado visual (visível, checado, cores,…); com os dados (texto, grids, labels,…); mensagens (dialogs, popups,…) e todo tipo de interação entre os componentes visuais e não-visuais.

Definir dezenas de métodos em formulários e DataModules parece ser comum. O programador cria um DataModule com queries e componentes relacionados, acrescenta 50 métodos e considera ter feito um ótimo trabalho na reutilização e organização do código — no entanto ele só criou mais uma classe inchada, seguindo o anti-padrão conhecido como a síndrome da classe Deus.

Nesse artigo você poderá aprender algumas técnicas para se livrar dessas classes com dezenas de métodos, difíceis de entender e gerenciar.

A culpa é do RAD?

Na minha opinião, Delphi sempre foi a melhor IDE para desenvolvimento de aplicações Desktop — até surgirem opções como Lazarus — e grande parte desse sucesso é devido ao conceito e uso do RAD (Rapid Application Development).

Largue um componente no formulário, defina algumas propriedades, implemente alguns eventos e pronto. Fácil. Rápido. Mas talvez, sujo.

Para prototipagem é ótimo. Você consegue mostrar ao cliente algo funcionando em minutos. Mas para código real, para a manutenção, esse tipo de design pode se tornar um pesadelo no médio prazo.

Mas a culpa não é do RAD. Ele é apenas uma ferramenta. Ferramentas sozinhas não fazem mal projetos. Os desenvolvedores fazem.

RAD foi feito para agilizar o desenvolvimento, especialmente no design de formulários. Mas levaram esse conceito tão longe que muitos desenvolvedores só conhecem esse caminho para o desenvolvimento, desde formulários, regras de negócio, até a persistência.

RAD significou o sucesso mas também a “desgraça” do Delphi. É por causa do RAD que o Delphi (até hoje) não é bem visto em círculos de desenvolvimento mais voltados a regras de negócio, padrões de projetos, aplicações em camadas, etc.

Mas, novamente, não é culpa do RAD. Não há nada de errado com RAD. O errado e tentar implementar tudo no modelo RAD, na minha opinião.

É mais fácil largar componentes no formulário e setar propriedades e eventos, do que pensar em padrões de projeto, orientação a objetos e desenvolvimento em camadas.

RAD funciona, mas não é sustentável no longo prazo.

Formulários sem Métodos

O uso indiscriminado do RAD pode deixar a aplicação tão acoplada que seria muito difícil ter camadas separadas entre GUI, regras de negócio e persistência.

Acredito que para remover o conceito de “RAD para tudo”, temos que começar com o básico, por exemplo, como desenvolver formulários com uma quantidade mínima de métodos.

A quantidade de métodos não está relacionado diretamente ao RAD — você pode ter uma classe com 100 métodos em qualquer linguagem, utilizando RAD ou não — no entanto, eu acredito que o RAD “estimula” essa prática, pois se todos os widgets e eventos estão declarados no formulário, onde mais eu iria implementar os métodos para lidar com esses componentes, certo?

Essa prática e muito comum, porém equivocada. Uma classe deveria ser pequena — menor quantidade de métodos possível — e coesa — todos os seus atributos são utilizados na maior quantidade de métodos possível. E fazer isso em um formulário e praticamente impossível.

A tendência é que cada novo método trabalhe com poucos widgets; os métodos terão uma nomenclatura tão verbosa quanto uma frase, pois todos irão fazer parte de uma mesma classe e não pode haver ambiguidade ou colisão de nomes.

Quantas vezes isso já aconteceu com você?

Seria possível termos formulários com o mínimo de métodos ou até nenhum e, mesmo assim, capazes de controlar as interações entre todos os widgets e componentes visuais e não-visuais?

A primeira prática que eu recomendo é separar widgets em frames — disponíveis no Delphi desde as primeiras versões através da classe TFrame.

Muitos formulários possuem tabs e cada tab pode ser um frame que desconhece completamente o formulário onde ele está contido.

Cada frame irá ter seu próprio conjunto de widgets, com nomenclatura simplificada, visto que não há colisões de nomes entre outros widgets se tudo estivesse em um mesmo formulário.

Esse é o primeiro nível da refatoração.

Mas isso não elimina a quantidade enorme de métodos que poderão existir, pois o desenvolvedor precisa por ação nos formulários e frames.

O segundo nível consiste em dividir para conquistar, eliminando quase que totalmente os métodos de um formulário.

Dividir para Conquistar

Independente de ser um formulário, frame ou DataModule, considere todos como sendo containers de componentes (visuais ou não).

O objetivo é dividir os métodos em pequenos objetos que irão fazer uso dos componentes do container.

Mesmo que esse artigo se refira a formulários complexos, vou lhe dar um exemplo simples, mostrando que com apenas 1 widget, poderíamos adicionar vários métodos ao formulário, erroneamente.

Considere uma instância de um TStatusBar para exibir informações da aplicação.

O usuário precisaria ver a versão da aplicação; o database em uso; o status atual de algum processamento.

Um StatusBar possui a propriedade Panels[]que é como um array de objetos de texto — dado um índice, você altera o texto naquela posição.

Um programador iniciante talvez iria utilizá-lo dessa forma:

StatusBar1.Panels[0].Text := version;
StatusBar1.Panels[1].Text := database;
StatusBar1.Panels[2].Text := 'Loading...';

Um programador mais experiente saberia que não se deve utilizar índices arbitrários pelo código — se quisermos mudar a posição de alguma informação, teríamos que percorrer todo o código para mudar os índices para novas posições. Esse programador provavelmente iria criar constantes para cada índice, o que resolveria a manutenção futura, no entanto teríamos constantes (verbosas) no código que estão “desacopladas” do objeto no qual elas atuam, ou seja, o StatusBar.

O código ficaria dessa forma:

const
  STATUSBAR_VERSION = 0;
  STATUSBAR_DATABASE = 1;
  STATUSBAR_STATUS = 2;

StatusBar1.Panels[STATUSBAR_VERSION].Text := version;
StatusBar1.Panels[STATUSBAR_DATABASE].Text := database;
StatusBar1.Panels[STATUSBAR_STATUS].Text := 'Loading...';

Veja o quão é verboso cada constante, pois é (quase) obrigatório utilizar prefixos para deixar claro em qual componente(s) esse “grupo de constantes” trabalham.

Outro tipo de desenvolvedor iria utilizar métodos no formulário. O exemplo abaixo pode ser meio extremo, mas considere que eu não poderia dar um exemplo real pois não caberia nesse artigo. Portanto, utilizar tais métodos não estaria tão longe da realidade:

  procedure SetStatusBarVersion(const aValue: string);
  procedure SetStatusBarDatabase(const aValue: string);
  procedure SetStatusBarStatus(const aValue: string);

Criando métodos no formulário elimina as constantes e índices, porém incha a classe do formulário.

Veja, também, o quão é verboso cada método, novamente utilizando prefixos longos e entediantes — nomes longos em métodos e variáveis são sinais de que eles podem não fazer parte da classe onde estão.

Foram adicionados 3 métodos para lidar com apenas 1 componente que exibe texto.

Finalmente, um arquiteto de software teria objetivos maiores como: reutilizar os métodos em outro formulário ou projeto; simplificar o formulário, removendo métodos que lidam apenas com poucos componentes; retirar índices e constantes arbitrárias; trabalhar com o StatusBar sem pensar que ele é um StatusBar, abstraindo-o.

TStatusBarWidget = class
private
  fOrigin: TStatusBar;
  fVersion: string;
  fDatabase: string;
  fStatus: string;
public
  constructor Create(aOrigin: TStatusBar); reintroduce;
  property Version: string read fVersion;
  property Database: string read fDatabase;
  property Status: string read fStatus write fStatus;
end;

Essa classe iria receber a instância do StatusBar real no construtor, inicializada no construtor do formulário; iria obter os dados da versão e database automaticamente, disponibilizando propriedades somente leitura; o status poderia ser atualizado e lido dentro dos eventos do formulário.

begin
   fStatusBar.Status := 'Loading...';
end;

Toda a lógica referente ao StatusBar estaria encapsulada dentro da classe TStatusBarWidget, podendo ser reutilizada em outro lugar.

Outros programadores que porventura trabalhem no código, não iriam precisar lembrar de índices ou constantes arbitrárias. Eles iriam utilizar apenas um único objeto com métodos bem definidos para cada atividade, abstraindo sobre o que esta acontecendo internamente ao objeto — a atualização do StatusBar.

O formulário não teria nenhum método (relacionado a StatusBar), contendo apenas um atributo privado do tipo TStatusBarWidget.

O exemplo é simples, porém acredito que você tenha visualizado que poderá utilizar essa técnica não apenas para encapsular um componente, mas também para todo um conjunto deles, implementando toda a interação entre eles num único objeto.

Conclusão

Toda vez que você nomear um método com nomenclatura composta, pare e pense se esse método deveria estar em outra classe.

Não implemente vários métodos numa única classe. Separe-os em objetos menores e coesos, mesmo que esses objetos trabalhem diretamente com os componentes do container.

É melhor ter vários objetos pequenos, mesmo que fortemente acoplados, do que por tudo num único objeto onde a manutenção irá se tornar um caos em pouco tempo.

Até logo.

Bônus

Eu fiz um Webinar sobre esse artigo.

Você pode baixar os fontes aqui.

Pascal Deveria ser Modernizado?

Mon, 19 Nov 2018 00:00:00 +0000

Ao longo dos anos, desde Turbo Pascal até as versões mais atuais do Delphi e Lazarus, temos visto muitas mudanças na linguagem.

Você acha que estamos modernizando a linguagem Object Pascal?

Photo by Hayes Potter on Unsplash

Introdução

É incrível como até hoje eu ainda tenho que responder perguntas sobre os motivos de continuar utilizando a linguagem Object Pascal.

Vou desenvolver utilizando Object Pascal — eu digo a um possível cliente.

Object Pas… Ah, aquela linguagem da Apple? (Objective C)
Acho que você quer dizer Delphi, não é?
Por quê você continua utilizando “isso”?
Por quê não utilizar C# ou Java?
Você ainda consegue achar emprego?

Eu já escrevi meus motivos mas entendo como pode ser difícil para a maioria das pessoas acreditarem.

Talvez eles pensem que Object Pascal não é tão moderno quanto as linguagens mainstream.

Quando o Concorrente é Prioridade

Existem linguagens muito mais “modernas” hoje em dia e escolher uma que “está morta” não parece uma opção razoável ~~para aqueles que só sabem seguir cegamente o que a maioria diz~~.

Se você quer chegar onde a maioria não chega, faça o que a maioria não faz — Bill Gates

Talvez esse sentimento de modernização está abalando até mesmo os diretores e desenvolvedores do atual Delphi.

A “modernização” a que me refiro pode ser simplificada dessa forma:

Se meu concorrente tem tal feature, eu preciso ter também.

E isso pode matar a linguagem.

Inline Variable Declarations

A alguns dias recebemos a notícia que a linguagem Delphi irá ter Inline Variables.

Marco Cantu — respeitado e conceituado no mundo Delphi — já começou a “matar” a sintaxe Pascal clássica de declaração de variáveis quando inicia seu artigo escrevendo “Old Style Var Blocks”.

Então é oficial, estamos defasados?

Na linguagem Object Pascal, declaramos as variáveis em blocos bem definidos e organizados, diferentemente de outras linguagens onde pode-se declarar onde quiser. Entretanto, agora isso parece ser ruim, já que a maioria faz diferente.

Solução? Ora, vamos copiar o concorrente!

O foco parece ser mais no que o concorrente anda fazendo nos compiladores deles do que nos seus fieis usuários e desenvolvedores Pascal.

Type Inference for Inline Variables

Na linguagem Pascal, tudo deve ser previamente declarado.

Tudo.

Isso é algo intrínseco a linguagem desde o seu nascimento e é um dos pontos fortes dela, pois minimiza qualquer ambiguidade na declaração de tipos.

Tem quem goste, tem quem odeie. Não importa. Ela foi feita dessa forma e deve ser respeitada.

Mas, agora temos a inferência de tipo.

Isso existe em outras linguagens mas é provável que você conheça através do C#.

E as pessoas “aplaudiram”…

Sim, pode ser considerada uma facilidade. Você irá escrever menos. E 99% dos programadores Object Pascal — especialmente Delphi — adoram uma facilidade sem se preocupar com o custo. Sim, o custo, por quê na engenharia nada vem de graça.

A compilação pode ficar mais lenta; pode haver erros de conversão obscuros; o código pode ficar menos legível… além de ir contra a própria filosofia da linguagem, que é declarar tudo antes.

Mesmo assim, se é fácil para escrever e o concorrente tem… por quê não?

Conclusão

Não há problemas com a declaração de variáveis atual. Esse é o estilo Pascal. Entretanto, parecem que estão mais preocupados em adicionar mais features a linguagem do que corrigir bugs. Bem, cada um sabe o que é melhor para sua empresa.

Trabalho com sistemas de alta performance que ainda utilizam a sintaxe clássica do Delphi 7. Então, posso afirmar que não é isso que irá deixar a linguagem melhor que seus concorrentes.

Não me entenda mal. Não estou dizendo que não podemos alterar a linguagem. Existem algumas features ou acertos que que seriam muito bem vindos como, por exemplo, a correção da sintaxe WITH-DO ou uma nova sintaxe para para determinar um alias para uma Unit. Esses seriam melhorias que iriam corrigir problemas no design da linguagem, melhorando a leitura do código e tudo de acordo com a filosofia e estilo Pascal.

Não quero um Frankenstein de várias linguagens. Quero um design limpo, simples e eficiente.

Não quero copiar o concorrente. Quero escrever código Object Pascal.

Não faz sentido levar seu BMW clássico ao mecânico dizendo para deixá-lo mais parecido com uma Mercedes-Benz mais moderna. Você acabará ficando com nenhum dos dois, apenas sucata.

Até logo.