Post: SO[L]ID – LSP – Princípio de substituição de Liskov

Alessandro Medeiros

Compartilhar no whatsapp
Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
Compartilhar no facebook
Fala ai Radizerios e Radizeiras, tudo bem com vocês?
Neste post falo de uma das técnicas usadas no meu dia a dia na programação.
Estarei mostrando para vocês o Princípio de substituição de Liskov.
 
Mas quem é Liskov?
 
Liskov é uma mulher chamada Barbara Liskov.
 
Em 1988 ela definiu que toda classe filha tem que a qualquer tempo ser substituída pela classe pai sem que seu funcionamento mude.
 
Já sei tudo…
 
Conhecemos abstração e aplicamos muito em nossos projetos.
 
Mas infelizmente pecamos em alguns processos de abstração e violamos o Liskov Substitution Principle ou Princípio de substituição de Liskov.
 
A abstração e herança, devem ser usados com responsabilidade para termos uma arquitetura leve e flexível em nossos projetos.
 
Esses conceitos são ensinados detalhadamente em um dos meus cursos POO AVANÇADO E PROGRAMAÇÃO FUNCIONAL.

 

 

Mesmo achando que estou certo eu estou errado.
 
Como queremos ter um nível de abstração perfeita acabamos trazendo problemas na arquitetura de nossos softwares.
 
Por este motivo estarei mostrando um problema de abstração que traz comportamentos inesperados em uma rotina de geração de arquivos.
 
No código abaixo temos a implementação que gera um arquivo txt.

...

var
    Arquivo : TArquivoTXT;
begin
    Arquivo := TArquivoTXT.Create;
    try
        Arquivo.GerarArquivo;
    finally
        Arquivo.Free;
    end;
end;

Na implementação de nossas classes vemos que possuímos a geração de arquivos diferentes.


type
    TArquivo = class
        procedure GerarArquivo; virtual; abstract;
    end;

type
    TArquivoTxt = class(TArquivo)
        procedure GerarArquivo; override;
    end;

type
    TArquivoWord = class(TArquivo)
        procedure GerarArquivo; override;
    end;

Veja que o método GerarArquivo da classe TArquivo, classe pai, é abstract, nesta situação ele já esta violando o principio de Liskov.
Porque se alterarmos a classe TArquivoTXT para TArquivo, não poderemos afirmar que irá funcionar, pois na classe pai o método não possui implementação.
Cada implementação do GerarArquivos nas outras classes terão responsabilidades especifica.
 
... 
var 
    Arquivo : TArquivo; 
begin 
    Arquivo := TArquivo.Create; 
    try 
        Arquivo.GerarArquivo; 
    finally 
        Arquivo.Free; 
    end; 
end; 

O que fazer para atender o principio de Liskov?

Neste ponto não iremos programar orientado a classe e sim orientado a interface.

Veja o código abaixo.


type
    iArquivo = interface
        procedure GerarArquivo;
    end;

type
    TArquivoTxt = class(TInterfacedObject,iArquivo)
        procedure GerarArquivo;
    end;

type
    TArquivoWord = class(TArquivoTxt)
        procedure GerarArquivo;
    end;

Criamos uma interface e uma classe que a implementa, e as demais classe herda dessa classe.

Nosso código irá sofrer uma pequena alteração, onde nossa variável não terá seu tipo a classe e sim a interface, desta forma podemos alterar a geração de arquivos para qualquer um tipo TXT,Word, ect…

Como a classe Pai implementa a interface iArquivo, as classes que descendem dela também a implementa por herança, podemos alterar a geração sem que venhamos violar o principio de Liskov.


...

var
    Arquivo : iArquivo;
begin
    Arquivo := TArquivoTxt.Create;
    Arquivo.GerarArquivo;
end;

Agora vamos gerar para Word.

...

var
    Arquivo : iArquivo;
begin
    Arquivo := TArquivoWord.Create;
    Arquivo.GerarArquivo;
end;

Vê como seguindo os padrões de Clean code nossos códigos ficam mais limpos e de fácil implementação, esse e outros padrões SOLID você pode encontrar em nosso curso de CLEAN CODE.

 

 

No nosso treinamento CLEAN CODE E BOAS PRATICAS DE PROGRAMAÇÃO EM DELPHI você aprenderá não só a usar o principio de Liskov, irá aprender de forma prática, técnicas que irão te ajudar a ter um código bem estruturado, organizado e preparado para as mudanças repentinas, afinal sabemos que a todo o momento seja por força do governo ou por solicitações de clientes, precisamos realizar alterações em nossos projetos, então porque não ter um código já preparado para essas mudanças? No treinamento, eu desenvolvi um método que alinha exemplos reais de aplicação das técnicas para resolver problemas do dia a dia, Como:

* Reutilização de código

* Fácil adaptação a novas tecnologias / componentes

* Fácil implementação de novas features

* Até 70% de redução no tempo de manutenção do código

* Redução de Bugs na entrega de novas implementações

Faça sua busca

CATEGORIAS

POSTS RECENTES

E caso você tem interesse de conhecer mais sobre SO[L]ID – LSP – Princípio de substituição de Liskov, acesse o nosso portal do CLUBE DE PROGRAMADORES EM DELPHI
Você não terá só conteúdos relacionados ao SO[L]ID – LSP – Princípio de substituição de Liskov, mas uma quantidade enorme de conteúdos que poderá lhe ajudar muito no seu dia a dia, é uma verdadeira NETFLIX para os programadores Delphi.
Gostou?
Compartilhe:
Compartilhar no whatsapp
Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
Compartilhar no facebook

Embarque no foguete com milhares de devs para aprender desenvolvimento, evoluir de forma contínua e se manter relevante no mercado.

Sobre
Dúvidas
Cadastre-se em nossa lista

Para ter acesso em primeira mão, a tudo que acontece na Academia do Código, basta se cadastrar em nossa lista

Grupo Thulio Bittencourt | Academia do Código

#FaçaPartedaHistória

Copyright © 2021 – Todos os direitos reservados