Pensando em Objetos

Jan 3, 2016
7 minute read
Como Pensar em Objetos?
Aqui vai uma resposta simples e direta:
Pensar em Objetos significa no implementar uma tarefa na forma de instrues passo-a-passo para o computador.

Pensar em Objetos uma mudana de paradigma enorme para quem comeou a programar em linguagens procedurais como C, ASM ou
Pascal e no conseguiu ou nunca quis mudar o mindset para entender como programar Orientado a Objetos.
A tempos aprendemos sobre Herana, Encapsulamento e Polimorfismo, mas eu acho que todos ns inclusive eu, no passado no
entendemos a transio do Procedural para o paradigma Orientado a Objetos.

Programando Orientado a Objetos

Nada melhor do que um exemplo prtico para comearmos a entender as diferenas entre programao Procedural e Orientada a Objetos.
Um cliente nos contratou. Um WebService est disponvel e precisamos construir um Client para consumi-lo.
Eu no quero utilizar um gerador automatizado de cdigo para ler o WSDL e gerar uma classe existe essa opo no Delphi e no Lazarus
instalando um package especfico.
Ento, hipoteticamente falando, temos um WebService simples com 5 mtodos. Cada mtodo tem os mesmos argumentos: usurio e senha.
As configuraes do WebService como Usurio, Senha, URL, mtodos do WebService que devero ser executados, horrio de execuo, etc.
esto num arquivo de configuraes. Porque isso? Bem, esse WebService ser executado em batch automaticamente em horrios prprogramados. E em cada horrio alguns mtodos sero executados, em outros no.
Como automatizado, precisamos de um Log. Em texto mesmo. Um Log que grave a execuo, mtodo, horrio, usurio/senha, exees, etc.
O cliente tambm quer testar o WebService utilizando um Form (GUI) para ver se est tudo funcionando, mostrando na tela o XML recebido
de acordo com o mtodo a ser executado, escolhido numa ComboBox. Quando o Form utilizado o sistema no precisa criar Log, mas precisa
mostrar excees na tela. Mas quando em execuo em batch, ele precisa gravar o Log de execuo e de excees.
Vejam que esse Client para o pessoal de Infra ento sem frescura mesmo: Log em texto, roda em batch e no tem tela bonita.
Para cada requisio, o Client precisa:
1. Trazer o XML;
2. Fazer um parser nos dados;
3. Fazer uma persistncia com os dados obtidos;
Aqui est o cdigo Procedural para consumir o WebService:
Ateno: Eu digitei a procedure diretamente no post, sem teste de compilao, ento podem haver erros de sintaxe.
procedure TDpvAction.Act(const WebMethodName: string);
var
Client: TDpvService;
Mapping: TDpvXMLMappingInTable;
XML: string;
XMLIterable: TXMLIterable;
begin
// FFileConfig um atributo da classe
Client := TDpvService.Create;
Mapping := TDpvXMLMappingInTable.Create;
XMLIterable := TXMLIterable.Create;
try
// Configura a URL do WebService
Client.SetURL(FFileConfig.ReadString('WebService', 'URL'));
// Configura com verificao de exceo
Client.WithCheck(True);
// Configura para gerar Log
Client.WithLog(True);
// Client executa o mtodo
XML := Client.ExecuteMethod(
FFileConfig.ReadString('WebService', 'User'),
FFileConfig.ReadString('WebService', 'Password'),
WebMethodName
);

// Obtm as configuraes necessrias

XMLIterable.SetXMLNodes(FFileConfig.ReadString('XMLNodes', WebMethodName));
// Configura o XML gerado
XMLIterable.SetXML(XML);
// Executa e gera outro XML (sim, reutilizei a mesma varivel)
XML := XMLIterable.Execute;

:)

// Executa a persistncia
Mapping.SetXML(XML);
Mapping.Execute;
finally
// No pode esquecer de desalocar tudo
Client.Free;
Mapping.Free;
XMLIterable.Free;
end;
end;

um cdigo Procedural e funciona (teoricamente).

Parece fcil de ler, mas o cdigo tem complexidade onde no deveria. As classes tem funes demais mesmo separando em classes,
continua procedural.
Reparou nas linhas em branco para facilitar a leitura? Fiz isso propositalmente por 2 motivos:
1. Queria destacar cada linha para voc ter mais contexto do problema;
2. Ainda no sei como alterar as configuraes do highlight para deixar o cdigo menos poludo quando eu usar comentrios :(
3. Todo mundo faz isso para facilitar a leitura certo? :)
Mas quando vocs programarem Orientado a Objetos, no haver mais motivos para pular linhas dentro de um mtodo, Ok?

Dica: Pular linhas dentro de um mtodo um mal cheiro no cdigo. Pode significar que voc est fazendo coisas demais num nico
mtodo.

Nesse tipo de cdigo, a cada manuteno, voc se preocupa em quebrar alguma coisa.
Para no quebrar nada voc precisa:
Chamar os mtodos na sequncia correta
Chamar os SetXXX na sequncia correta
Ter cuidado com as variveis, suas inicializaes e reutilizao
Instanciar os objetos na sequncia correta
Etc.
No tome cuidado e BUMM! Quebrou o cdigo. Debugg. Checagem das atribuies na sequncia exata. Perda de tempo.
No? Voc sabe que verdade :)
O cdigo apresentado 100% Procedural, mesmo utilizando classes! Voc poderia usar mais classes e at mesmo Herana entre elas, mas o
cdigo continuaria Procedural. Voc no tem objetos, voc tem funes agrupadas em blocos (classes) para fazer aes para o
orquestrador, voc!

E como estes mesmos requisitos poderiam ser codificados utilizando Orientao a Objetos, sem um orquestrador, utilizando objetos vivos
com encapsulamento perfeito, minimizando a quebra de cdigo em manutenes futuras e com um cdigo muito mais elegante?
Aqui est o cdigo Orientado a Objetos para consumir o mesmo WebService:
function TDpvAction.Act(const WebMethodName: string): IActionResult;
begin
Result := TDpvXMLMappingInTable.New(
FFileConfig.ReadString('MethodsVsTables', WebMethodName),
TDpvXMLIterable.New(
FFileConfig.ReadString('XMLNodes', WebMethodName),
TDpvServiceWithLogging.New(
TDpvServiceWithChecking.New(
TDpvService.New(
FFileConfig.ReadString('WebService', 'URL')
)
)
)
.Call(
TDpvMethod.New(
WebMethodName,
TWebAuthorization.New(
FFileConfig.ReadString('WebService', 'User'),
FFileConfig.ReadString('WebService', 'Password')
)
)
).XML
)
).Act;
end;

Esse um cdigo verdadeiramente Orientado a Objetos. No dizemos ao computador linha-a-linha sobre o que fazer. Os Objetos sabem o
que fazer! Eles no precisam de um orquestrador lhes dizendo o que fazer a cada momento. Crie-os j configurados e deixe-os conversarem
entre si. Eles sabem os mtodos a chamar e quando cham-los. Eles podem criar objetos internamente ou no e isso irrelevante para o
cdigo chamador. Eles so como uma caixa preta, ningum sabe o que h dentro deles. Voc, o programador, s precisa saber o contrato
que o objeto dever cumprir. Esse contrato chamamos de interface.
No d pra ver no cdigo por motivos de simplificao, mas cada instncia do tipo de uma interface, por isso temos os mtodos New
um padro que eu defini para meus projetos para contornar uma feature do compilador mas s irei falar a respeito em outros posts.
Ao invs de uma procedure agora temos uma function que retorna um IActionResult e o fato de ter apenas um Result um timo sinal
de que a funo no faz coisas demais. Essa funo como um grande objeto ou uma composio deles vou falar mais sobre isso em
futuros posts.
Se todas as instncias so do tipo interface, ento no preciso desalocar nada manualmente deixando o cdigo mais clean sem try-finally
e sem memleaks (caso esquea algum .Free).
Todos os objetos so imutveis, ou seja, aps criados no h nenhum SetXXX que altere seu estado interno. Ento no configuro meu
Client, e nenhum outro objeto, utilizando mtodos SetXXX para ele trabalhar com Log ou com checagem de excees.

Dica: Toda classe deveria ser imutvel, a no ser que tenha uma tima razo para no ser.

Eu uso Decorators ao invs de properties ou SetXXX para ligar/desligar flags (atributos). Assim no preciso completar a(s) classe(s)
numa sequncia correta de chamadas dos mtodos.

Se eu no preciso do Log, no utilizo o decorator do Service de Log que chamei de TDpvServiceWithLogging; o mesmo para a checagem
de Excees, que chamei de TDpvServiceWithChecking.
O mtodo de chamada no WebService uma classe separada, que chamei de TDpvMethod. Cada autorizao (usurio/senha) tambm uma
classe, que chamei de TWebAuthorization enfim.
Viu as diferenas?
Espero que voc tenha visto as vantagens de programar Orientado a Objetos, mesmo com esse exemplo simples.
T gostando? Alguma dvida? No concorda? Posta a nos comentrios.
Vejo voc no prximo post.

Dica: Sugiro a leitura do livro Object Thinking de David West. Leia-o com a mente aberta e comear a entender mais sobre o Pensamento

Objeto.
Compartilhe

2 comentrios
Object Pascal Programming
Entrar
1
Recommend
Compartilhar
Ordenar por Melhor avaliado

Participe da discusso...

o
o

Mario Junior 10 dias atrs

Muito boa a publicao! Ajuda muito na reflexo do paradigma da orientao a objeto. Muitos profissionais se enganam ao
acreditarem que por estarem criando classes e mtodos, j esto utilizando POO. Gostaria de sugerir tambm outro livro sobre o
assunto: Clean Code ("Cdigo Limpo" na verso brasileira) do autor Robert C. Martin.
Abraos.
o
o
o
o
o

Responder

Compartilhar

o
o

Marcos Douglas Santos Mod Mario Junior 10 dias atrs

J ouvi falar desse livro. Caro, mas deve valer muito a pena. Valeu a dica!

Responder

Compartilhar