O que são os princípios SOLID? Guia para iniciantes dos 5 princípios fundamentais do design orientado a objetos [Com exemplos em Python]

Ao escrever código, é comum começar com algo que funciona, mas conforme o projeto cresce, surgem situações como:

• Uma classe que cresce para centenas de linhas e ninguém quer mexer — a \u201Cclasse Deus\u201D
• Código que você mesmo escreveu há meses e não consegue mais entender
• Cada nova funcionalidade exige alterar código existente, e adicionar algo novo vira motivo de medo
• Corrigir um lugar quebra outro sem motivo aparente

Isso não é falta de habilidade individual — é um problema de design. Se não pensarmos na \u201Cestrutura\u201D do código, além da sintaxe, o projeto inevitavelmente se torna complexo e impossível de manter.

Os princípios SOLID foram propostos justamente para evitar esse cenário. SOLID reúne cinco princípios fundamentais do design orientado a objetos, sistematizados por Robert C. Martin (Uncle Bob) no início dos anos 2000. Hoje, são usados como base de design em praticamente todo desenvolvimento de software: web, IA/ML, jogos, embarcados e muito mais.

Este guia explica cada um dos cinco princípios: por que existem, comparações entre design ruim e bom, exemplos em Python e aplicações práticas. Os conceitos valem para qualquer linguagem, mas os exemplos usam Python.

Visão geral dos princípios SOLID

Em resumo, SOLID são regras de design para escrever código resiliente a mudanças, que quebra menos e se estende com mais facilidade.

Por que os princípios SOLID são necessários

Para entender a importância do SOLID, veja um exemplo de design ruim:

class UserManager:
    def register(self, name, email):
        # cadastro de usuário
        pass

    def send_welcome_email(self, email):
        # envio de e-mail
        pass

    def save_to_database(self, user):
        # persistência em DB
        pass

    def generate_monthly_report(self):
        # geração de relatório
        pass

    def validate_input(self, data):
        # validação de entrada
        pass

Essa classe parece conveniente, mas tem problemas sérios:

É um design em que \u201Cuma mudança quebra tudo\u201D. Quanto maior o projeto, pior fica. SOLID existe para evitar isso.

Com SOLID, o cenário muda:

S: Responsabilidade Única (Single Responsibility Principle)

Uma classe, um papel. A classe deve ter apenas um motivo para ser alterada.

É o princípio mais básico e importante do SOLID. \u201CResponsabilidade\u201D pode ser entendida como \u201Cmotivo de mudança\u201D. Se uma classe tem vários motivos para mudar, ela está com responsabilidades demais.

Exemplo ruim: responsabilidades misturadas

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

    def save(self):
        # persistir no DB (responsabilidade de persistência)
        pass

    def send_email(self, subject, body):
        # envio de e-mail (responsabilidade de notificação)
        pass

    def calculate_age(self, birthdate):
        # cálculo de idade (responsabilidade de regra de negócio)
        pass

Essa classe tem três motivos de mudança: alteração de esquema de DB, mudança no serviço de e-mail e mudança na lógica de cálculo de idade. Qualquer um pode impactar os outros.

Exemplo bom: responsabilidades separadas

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

class UserRepository:
    def save(self, user: User):
        # persistir no DB
        pass

class EmailService:
    def send(self, to: str, subject: str, body: str):
        # envio de e-mail
        pass

class AgeCalculator:
    def calculate(self, birthdate) -> int:
        # cálculo de idade
        pass

O: Aberto/Fechado (Open/Closed Principle)

O software deve estar aberto para extensão e fechado para modificação.

Ou seja: novas funcionalidades devem ser adicionadas sem alterar o código existente. Modificar código antigo aumenta o risco de bugs. Se for possível estender sem modificar, o risco de quebrar o que já funciona cai.

Exemplo ruim: extensão via condicionais

class DiscountCalculator:
    def calculate(self, customer_type: str, price: float) -> float:
        if customer_type == \u0022normal\u0022:
            return price * 0.9
        elif customer_type == \u0022vip\u0022:
            return price * 0.8
        elif customer_type == \u0022super_vip\u0022:
            return price * 0.7
        # cada novo tipo exige alterar aqui...

Cada novo tipo de cliente exige alterar esse método. Cada alteração pode quebrar os cálculos já existentes.

Exemplo bom: extensão por herança e polimorfismo

from abc import ABC, abstractmethod

class Discount(ABC):
    @abstractmethod
    def calculate(self, price: float) -> float:
        pass

class NormalDiscount(Discount):
    def calculate(self, price: float) -> float:
        return price * 0.9

class VipDiscount(Discount):
    def calculate(self, price: float) -> float:
        return price * 0.8

# novo tipo de desconto sem alterar o existente
class SuperVipDiscount(Discount):
    def calculate(self, price: float) -> float:
        return price * 0.7

Para adicionar um novo tipo de desconto, basta criar uma nova classe. As classes NormalDiscount e VipDiscount permanecem intactas.

L: Substituição de Liskov (Liskov Substitution Principle)

Onde a classe pai é usada, a subclasse deve poder substituí-la sem quebrar o comportamento esperado.

Herança deve ser usada quando há relação \u201Cis-a\u201D (X é um tipo de Y). Se a subclasse quebra o contrato da classe pai, o código que a usa pode falhar de forma inesperada.

Exemplo ruim: herança que quebra o contrato

class Bird:
    def fly(self):
        return \u0022Flying!\u0022

class Penguin(Bird):
    def fly(self):
        raise Exception(\u0022Penguins can't fly!\u0022)

# código que usa quebra
def make_bird_fly(bird: Bird):
    return bird.fly()  # exceção se receber Penguin

Penguin herda de Bird, mas quebra o contrato de fly(). Ao passar um Penguin para código que espera Bird, ocorre exceção.

Exemplo bom: hierarquia adequada

class Bird:
    def eat(self):
        return \u0022Eating!\u0022

class FlyingBird(Bird):
    def fly(self):
        return \u0022Flying!\u0022

class Penguin(Bird):
    def swim(self):
        return \u0022Swimming!\u0022

class Eagle(FlyingBird):
    pass

# seguro: fly só é exigido de FlyingBird
def make_bird_fly(bird: FlyingBird):
    return bird.fly()

Separando \u201Cave\u201D e \u201Cave que voa\u201D, Penguin não precisa implementar fly().

I: Segregação de Interfaces (Interface Segregation Principle)

O cliente não deve ser obrigado a depender de métodos que não usa.

Em vez de uma interface grande, prefira interfaces menores, com apenas o que cada cliente precisa.

Exemplo ruim: interface grande demais

from abc import ABC, abstractmethod

class Worker(ABC):
    @abstractmethod
    def work(self):
        pass

    @abstractmethod
    def eat(self):
        pass

    @abstractmethod
    def sleep(self):
        pass

class Robot(Worker):
    def work(self):
        return \u0022Working!\u0022

    def eat(self):
        raise NotImplementedError(\u0022Robots don't eat\u0022)

    def sleep(self):
        raise NotImplementedError(\u0022Robots don't sleep\u0022)

Robot precisa implementar eat() e sleep(), mas robôs não comem nem dormem. A interface força métodos desnecessários.

Exemplo bom: interfaces segregadas

from abc import ABC, abstractmethod

class Workable(ABC):
    @abstractmethod
    def work(self):
        pass

class Eatable(ABC):
    @abstractmethod
    def eat(self):
        pass

class Sleepable(ABC):
    @abstractmethod
    def sleep(self):
        pass

class Human(Workable, Eatable, Sleepable):
    def work(self):
        return \u0022Working!\u0022
    def eat(self):
        return \u0022Eating!\u0022
    def sleep(self):
        return \u0022Sleeping!\u0022

class Robot(Workable):
    def work(self):
        return \u0022Working!\u0022

Robot implementa apenas Workable. Human implementa as três. Robot não é forçado a ter eat() ou sleep().

D: Inversão de Dependências (Dependency Inversion Principle)

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.

Em vez de depender de implementações concretas (MySQL, SendGrid etc.), dependa de abstrações (interfaces). Assim fica mais fácil trocar implementações.

Exemplo ruim: dependência direta da implementação

class MySQLDatabase:
    def save(self, data):
        # salvar no MySQL
        pass

class UserService:
    def __init__(self):
        self.db = MySQLDatabase()  # dependência direta

    def create_user(self, name):
        self.db.save({\u0022name\u0022: name})

UserService depende diretamente de MySQL. Para migrar para PostgreSQL, seria preciso alterar UserService. Também não dá para usar um DB mock nos testes.

Exemplo bom: dependência de abstração + injeção de dependência

from abc import ABC, abstractmethod

class Database(ABC):
    @abstractmethod
    def save(self, data):
        pass

class MySQLDatabase(Database):
    def save(self, data):
        # salvar no MySQL
        pass

class PostgreSQLDatabase(Database):
    def save(self, data):
        # salvar no PostgreSQL
        pass

class UserService:
    def __init__(self, db: Database):  # depende da abstração
        self.db = db

    def create_user(self, name):
        self.db.save({\u0022name\u0022: name})

# uso
service = UserService(MySQLDatabase())
# trocar DB é simples
service = UserService(PostgreSQLDatabase())

UserService depende da abstração Database. MySQL, PostgreSQL ou um mock de teste podem ser injetados sem alterar UserService.

Antes e depois de aplicar SOLID

No curto prazo, aplicar SOLID pode parecer trabalhoso (mais classes). Com o tempo, o retorno aparece: projetos maiores se beneficiam bastante.

Uso na prática

SOLID não é só teoria; está presente em boa parte do desenvolvimento moderno.

Em APIs com frameworks web em Python, SOLID aparece em: separar roteamento, regras de negócio e acesso a dados (SRP), adicionar funcionalidades via middlewares (OCP), abstrair o banco para facilitar testes (DIP). Em padrões de segurança em Python, separar validação, autenticação e autorização também é SRP.

Ordem de estudo recomendada

Não é preciso dominar os cinco princípios de uma vez. Uma ordem sugerida:

Equívocos comuns

O que estudar depois de SOLID

Perguntas frequentes

Iniciantes devem aprender SOLID?

Sim, quanto antes melhor. Hábitos de design são difíceis de mudar depois. Ter desde cedo a pergunta \u201Cqual o motivo de mudar esta classe?\u201D já faz diferença.

SOLID vale para Python?

Sim. SOLID é design, não linguagem. Vale para Python, Java, C++, TypeScript, Go e qualquer linguagem com OOP. Em Python, por ser dinâmico, o design tende a ser ainda mais importante.

Preciso seguir os cinco princípios?

No início, SRP já basta. Os outros aparecem naturalmente com a experiência.

Quando pensar em SOLID?

Ao desenhar classes e módulos: ao criar uma nova classe, quando uma classe cresce demais ou quando os testes ficam difíceis de escrever.

SOLID é difícil?

Pode parecer abstrato no começo, mas com prática fica natural. SRP e OCP costumam ser os mais fáceis de sentir na pele.

Resumo

Os princípios SOLID são cinco regras de design para código mais resiliente a mudanças, menos propenso a quebrar e mais fácil de estender.

• S (Responsabilidade Única): uma classe, um papel; um motivo para mudar
• O (Aberto/Fechado): estender sem modificar o existente
• L (Substituição de Liskov): subclasses respeitam o contrato da classe pai
• I (Segregação de Interfaces): não forçar funcionalidades desnecessárias
• D (Inversão de Dependências): depender de abstrações, não de implementações

SOLID não é para decorar, é para entender. Saber por que existe ajuda a aplicar no dia a dia. Comece pela Responsabilidade Única e vá evoluindo.

Artigos relacionados: Guia de Introdução ao Python / 7 Padrões de Tratamento de Erros em Python / Comparação de Frameworks Web em Python / 10 Padrões de Segurança em Python / Guia de Comparação de Linguagens de Programação