DEV Community

Cover image for [S.O.L.I.D.] Os Cinco Pilares da Programação Orientada a Objetos. [L] - Liskov Substitution Principle - LSP
Diego de Sousa Brandão
Diego de Sousa Brandão

Posted on

2

[S.O.L.I.D.] Os Cinco Pilares da Programação Orientada a Objetos. [L] - Liskov Substitution Principle - LSP

Continuando a série sobre SOLID, caso não tenha lido o artigo anterior:

Neste artigo estarei falando sobre o terceiro princípio que é:

[L] -Liskov Substitution Principle
Princípio da Substituição de Liskov - LSP
“Se para cada objeto o1 do tipo S há um objeto o2 do tipo T de forma que, para todos os programas P definidos em termos de T, o comportamento de P é inalterado quando o1 é substituído por o2 então S é um subtipo de T.”

O Princípio de Substituição de Liskov leva esse nome por ter sido criado por Barbara Liskov, em 1988.

Tal definição foi resumida e popularizada por Robert C. Martin (Uncle Bob), em seu livro “Agile Principles Patterns and Practices”, como:

“Classes derivadas devem poder ser substitutas de suas classes base”

Ou seja, toda classe derivada deve poder ser usada como se fosse a classe base.

Para mim, foi um dos conceitos mais difíceis de entender. Portanto, não se preocupe se não conseguir compreender de imediato. Tenho esperança de que, com os exemplos de código, você sairá deste artigo entendendo esse princípio.

Vamos criar um sistema de notificações onde inicialmente temos um EmailNotification e, posteriormente, adicionamos um SMSNotification.

Veremos como implementar isso sem e com o LSP.

Sem LSP
Classe Notification e EmailNotification sem LSP
Image description

Adicionando SMSNotification sem LSP
Image description

Neste exemplo, a classe SMSNotification altera o comportamento esperado ao adicionar uma verificação de número de telefone, o que pode causar problemas quando substituímos a classe base Notification pela classe derivada SMSNotification.

Image description

Com LSP
Para seguir o LSP, devemos projetar nossas classes de forma que respeitem as expectativas da superclasse e evitem adicionar comportamentos que possam quebrar a substituição.

Interface Notification
Image description

Classe EmailNotification
Image description

Classe SMSNotification
Image description

Uso das Classes
Image description

Explicação:

  • Interface Notification: Define o contrato para uma notificação. Todas as notificações devem implementar os métodos setRecipient, setMessage e send.
  • Classe EmailNotification: Implementa a interface Notification e define a lógica específica para enviar um email.
  • Classe SMSNotification: Implementa a interface Notification e define a lógica específica para enviar um SMS. A verificação do número de telefone é feita no método setRecipient, garantindo que qualquer configuração inválida seja tratada antes de tentar enviar a notificação.
  • Uso das Classes: Demonstramos como criar e usar instâncias de EmailNotification e SMSNotification de forma intercambiável através da interface Notification, respeitando o LSP.

Ao seguir o Princípio da Substituição de Liskov, garantimos que nossas subclasses podem ser usadas em qualquer contexto onde a superclasse é esperada, sem alterar o comportamento correto do programa. Isso torna o código mais robusto e facilita a manutenção e extensão do sistema.

PS: Para ir direto para o próximo princípio:

Postmark Image

Speedy emails, satisfied customers

Are delayed transactional emails costing you user satisfaction? Postmark delivers your emails almost instantly, keeping your customers happy and connected.

Sign up

Top comments (0)

Billboard image

Create up to 10 Postgres Databases on Neon's free plan.

If you're starting a new project, Neon has got your databases covered. No credit cards. No trials. No getting in your way.

Try Neon for Free →

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay