Quais são os princípios SOLID?

Question

Accepted Answer

**SOLID** são cinco princípios de design para construir sistemas OOP mantíveis e flexíveis. Cada um aborda uma causa comum de código rígido e frágil.

## Os cinco princípios

| Letra | Princípio | Significado em uma linha |
|---|---|---|
| **S** | Single Responsibility | Uma classe deve ter um único motivo para mudar |
| **O** | Open/Closed | Aberto para extensão, fechado para modificação |
| **L** | Liskov Substitution | Subtipos devem ser utilizáveis onde o tipo base é usado |
| **I** | Interface Segregation | Muitas interfaces pequenas são melhores que uma grande |
| **D** | Dependency Inversion | Dependa de abstrações, não de classes concretas |

## Dois em código

```python
# Dependency Inversion: high-level code depends on an abstraction
class Notifier:                      # abstraction
    def send(self, msg): ...

class EmailNotifier(Notifier):
    def send(self, msg): print("email:", msg)

class OrderService:
    def __init__(self, notifier: Notifier):   # injected abstraction
        self.notifier = notifier              # not "new EmailNotifier()"
    def place(self):
        self.notifier.send("order placed")    # works with ANY Notifier
```

`OrderService` não depende especificamente de email — substitua por SMS ou um test double sem tocá-lo (D). Adicionar um novo tipo de notificador não requer mudança em `OrderService` (O).

## Armadilha

SOLID é uma orientação, não uma lei. Aplicá-lo em excesso — uma interface por classe, indireção em toda parte — produz "abstraction soup" que é mais difícil de seguir do que o problema que resolveu.

## Por que isso importa

SOLID fornece uma linguagem diagnóstica compartilhada: revisores podem nomear *por que* uma classe é difícil de mudar ("isso viola SRP") em vez de discutir por gosto.

Aplicados com bom senso, os princípios reduzem efeitos cascata — mudanças permanecem locais, novas funcionalidades se estendem em vez de serem reescritas, e testes podem substituir falsificações por dependências reais.

S	Single Responsibility	Uma classe deve ter um único motivo para mudar
O	Open/Closed	Aberto para extensão, fechado para modificação
L	Liskov Substitution	Subtipos devem ser utilizáveis onde o tipo base é usado
I	Interface Segregation	Muitas interfaces pequenas são melhores que uma grande
D	Dependency Inversion	Dependa de abstrações, não de classes concretas