[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:

[S.O.L.I.D.] Os Cinco Pilares da Programação Orientada a Objetos. [O] - Open/Closed Principle - OCP

Diego de Sousa Brandão ・ May 25

#java #solidprinciples

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

Adicionando SMSNotification sem LSP

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.

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

Classe EmailNotification

Classe SMSNotification

Uso das Classes

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:

[S.O.L.I.D.] Os Cinco Pilares da Programação Orientada a Objetos. [I] - Interface Segregation Principle - ISP

Diego de Sousa Brandão ・ May 25

#java #solidprinciples