Os princípios SOLID são considerados regras de ouro para criar um código robusto e flexível. Criados pelo renomado Robert C. Martin, eles são fundamentais para um design orientado a objetos limpo e sustentável:

1. Princípio da Responsabilidade Única (SRP)
2. Princípio Aberto/Fechado (OCP)
3. Princípio de Substituição de Liskov (LSP)
4. Princípio da Segregação de Interfaces (ISP)
5. Princípio da Inversão de Dependência (DIP)

O Princípio de Substituição de Liskov (LSP) é o herói desconhecido que garante que substituir um objeto por outro não quebre seu sistema. Ele reforça a estrutura lógica e a confiabilidade em seu código:

O que é o LSP?

Nomeado em homenagem à cientista da computação Barbara Liskov, este princípio é baseado na ideia de que você deve poder substituir uma classe pai por uma de suas subclasses sem quebrar seu código.

Por exemplo, um software projetado para carros autônomos deve funcionar com qualquer veículo. Se funcionar bem com um carro, mas falhar com um caminhão, o LSP foi violado. O código confiou demais no pai e não considerou o comportamento dos filhos.

Por que o LSP é importante?

O LSP é essencial para a extensão dos sistemas. Um sistema que segue o LSP oferece:

• Sem falhas inesperadas – A troca de subclasses não quebra o programa, pois são consistentes com a superclasse.
• Expansão sem medo – LSP garante que novos elementos se integrem sem problemas adicionais.
• Correção facilitada – Permite ajustes sem reescrever todo o código.
• Testes simplificados – Comportamentos consistentes tornam os testes mais fáceis.

Substituir subclasses sem quebrar o código

No cerne do LSP está a confiança. Você deve substituir uma classe pai por uma classe filha e esperar que tudo funcione bem. Uma subclasse não deve exigir mais do que a classe pai ou entregar menos do que prometido.

Pré-condições

São as condições que devem ser verdadeiras antes de um método ser executado. Uma subclasse não deve exigir mais do que a superclasse.

Pós-condições

São os resultados garantidos após a execução de um método. A subclasse não deve entregar menos do que a superclasse prometeu.

Entendendo o LSP com uma analogia do mundo real

Parece lógico dizer que um quadrado é um retângulo com lados iguais, certo? No entanto, ao tratar o quadrado como subclasse de um retângulo, violamos o LSP. A classe Quadrado que impõe lados iguais não pode substituir de forma confiável uma classe Retângulo que pressupõe largura e altura independentes.

Violações do LSP: O que dá errado e como corrigir

Mesmo compreendendo o LSP, é fácil violá-lo. A violação pode surgir quando a subclasse altera um comportamento prometido pela superclasse, causando exceções inesperadas.

Problema do quadrado-retângulo: Quando a subclasse leva a comportamentos incorretos

Ao forçar uma relação de herança onde o comportamento diverge, é melhor manter entidades separadas, permitindo que existam como formas independentes que compartilham características em comum.

Métodos lançando exceções inesperadas

O LSP é frequentemente violado quando uma subclasse remove ou altera um comportamento prometido pela superclasse, resultando em exceções inesperadas.

Valores de retorno inesperados

Outra violação comum do LSP ocorre quando uma subclasse retorna algo inesperado, que o sistema não está preparado para lidar.

LSP em diferentes linguagens de programação

Independentemente da linguagem de programação, a ideia central do Liskov Substitution Principle (LSP) permanece a mesma: subclasses devem ser substitutos confiáveis para suas superclasses.

LSP em Python

No Python, a tipagem dinâmica e o duck typing exigem cuidado para garantir que a subclasse se comporte como a superclasse.

from abc import ABC, abstractmethod

class Bird(ABC):
   @abstractmethod
   def fly(self) -> None:
       pass

class Sparrow(Bird):
   def fly(self) -> None:
       print("Sparrow flying")  # satisfaz o contrato
# Código cliente
def let_it_fly(b: Bird):
   b.fly()

Programando para uma base abstrata, qualquer subclasse que suporte fly() pode ser usada de forma intercambiável.

LSP em Java

Java, com seu sistema de tipos estáticos, reforça a necessidade do LSP, garantindo que subclasses possam se integrar sem comprometer a estrutura.

interface Shape {
   double area();
}
class Circle implements Shape {
   private final double radius;
   public Circle(double r) { radius = r; }
   public double area() { return Math.PI * radius * radius; }
}

Qualquer subclasse que implemente area() deve respeitar o contrato original, sem efeitos colaterais inesperados, e o resultado deve ser sempre um valor positivo.

LSP em TypeScript

Em TypeScript, a tipagem estática garante que subclasses mantenham assinaturas de método consistentes.

interface ButtonProps { onClick: () => void; label: string; }


function PrimaryButton(props: ButtonProps) {
   return {props.label};
}


function IconButton(props: ButtonProps & { icon: string }) {
   return 
        {props.label}
   ;
}

public interface IRepository {
   T GetById(int id);
}
public class SqlRepository : IRepository {
   public T GetById(int id) {
       // buscar no banco de dados SQL
   }
}

Angular services:
@Injectable({ providedIn: 'root' })
export abstract class AuthService {
   abstract login(credentials: Credential): Observable;
}


@Injectable()
export class RealAuthService extends AuthService {
   login(c: Credential) { /* chamada http */ }
}