Princípios SOLID

No Hands-on 1, o AccountService começa pequeno: criar, ler, apagar. Depois alguém adiciona validação de e-mail, um e-mail de boas-vindas, um log de auditoria, uma regra de desconto por tipo de cliente, uma importação em massa para administradores… Seis meses depois, a classe tem 600 linhas, cada mudança quebra um teste que não tem nada a ver com ela, e ninguém consegue fazer um teste unitário sem um banco de dados e um servidor SMTP. Nada disso ainda é um problema de arquitetura — é um problema de projeto de classes, e o SOLID é o vocabulário para tratá-lo.

SOLID é um acrônimo para cinco princípios de projeto orientado a objetos reunidos por Robert C. Martin¹. Ele os descreveu juntos pela primeira vez no artigo Design Principles and Design Patterns, de 2000, e no livro Agile Software Development: Principles, Patterns, and Practices (2002); o acrônimo em si foi sugerido por Michael Feathers por volta de 2004. Esses princípios atuam no nível das classes e dos módulos — são os blocos de construção que a Clean Architecture e a Arquitetura Hexagonal impõem no nível do sistema.

Letra	Princípio	Proposto por
S	Princípio da Responsabilidade Única (Single Responsibility)	Robert C. Martin
O	Princípio Aberto/Fechado (Open/Closed)	Bertrand Meyer, 1988²
L	Princípio da Substituição de Liskov (Liskov Substitution)	Barbara Liskov, 1987; formalizado com Jeannette Wing em 1994³
I	Princípio da Segregação de Interfaces (Interface Segregation)	Robert C. Martin
D	Princípio da Inversão de Dependência (Dependency Inversion)	Robert C. Martin

flowchart LR
    S["S — Responsabilidade Única\nUm motivo para mudar"] -->|compõe| arch
    O["O — Aberto / Fechado\nEstenda, não modifique"] -->|compõe| arch
    L["L — Substituição de Liskov\nSubtipos honram contratos"] -->|compõe| arch
    I["I — Segregação de Interfaces\nSem dependências forçadas"] -->|compõe| arch
    D["D — Inversão de Dependência\nDependa de abstrações"] -->|compõe| arch
    arch["Arquitetura\nClean / Hexagonal"]:::highlight
    classDef highlight fill:#fcc

S — Princípio da Responsabilidade Única

"Uma classe deve ter um, e apenas um, motivo para mudar." — Robert C. Martin

Uma classe responde a um ator⁴. Um ator é um grupo de usuários ou de partes interessadas que se importam com a mesma preocupação. Se uma classe atende a dois atores, as mudanças pedidas por um correm o risco de quebrar funcionalidades do outro.

O que o SRP NÃO significa

O SRP não significa que uma classe deve fazer só uma coisa. Significa que uma classe deve ter um único motivo para mudar — um dono. Uma classe de serviço pode orquestrar vários passos, mas, se todos esses passos atendem à mesma preocupação de negócio e à mesma parte interessada, a classe tem uma única responsabilidade.

Violação

Aplicado

AccountService.java — too many concerns
// VIOLATION: one class handles validation, persistence, email, and audit
// Every time any of these concerns changes, this class must be modified.
public class AccountService {

    private final DataSource dataSource;
    private final JavaMailSender mailSender;
    private final Logger logger = Logger.getLogger(AccountService.class.getName());

    public AccountService(DataSource dataSource, JavaMailSender mailSender) {
        this.dataSource = dataSource;
        this.mailSender = mailSender;
    }

    public void createAccount(String email, String password) {

        // 1. Validation — business concern
        if (email == null || !email.contains("@"))
            throw new IllegalArgumentException("Invalid email: " + email);
        if (password == null || password.length() < 8)
            throw new IllegalArgumentException("Password too short");

        // 2. Persistence — infrastructure concern
        try (Connection conn = dataSource.getConnection()) {
            PreparedStatement stmt = conn.prepareStatement(
                "INSERT INTO accounts (email, password_hash) VALUES (?, ?)");
            stmt.setString(1, email);
            stmt.setString(2, BCrypt.hashpw(password, BCrypt.gensalt()));
            stmt.execute();
        } catch (SQLException e) {
            throw new RuntimeException("Failed to persist account", e);
        }

        // 3. Email notification — messaging concern
        SimpleMailMessage msg = new SimpleMailMessage();
        msg.setTo(email);
        msg.setSubject("Welcome to the Platform!");
        msg.setText("Your account has been created. You can now log in.");
        mailSender.send(msg);

        // 4. Audit log — cross-cutting concern
        logger.info("Account created for email=" + email
            + " at=" + Instant.now());
    }
}

Esta classe tem quatro motivos para mudar: uma regra de validação diferente, uma mudança no esquema do banco de dados, um novo template de e-mail ou um formato de auditoria diferente — todos exigem modificar o mesmo arquivo.

AccountService.java — focused on orchestration
// Single responsibility: orchestrate the account-creation use case.
// Validation, persistence, email, and audit are delegated to specialists.
public class AccountService {

    private final AccountRepository repository;
    private final EmailService emailService;
    private final AuditService auditService;

    public AccountService(AccountRepository repository,
                          EmailService emailService,
                          AuditService auditService) {
        this.repository   = repository;
        this.emailService = emailService;
        this.auditService = auditService;
    }

    public Account create(AccountIn in) {
        Account account = Account.of(in);           // validation inside domain object
        repository.save(account);                   // persistence
        emailService.sendWelcome(account.email());  // notification
        auditService.log("account.created", account.id()); // audit
        return account;
    }
}

Cada classe especialista muda apenas pelo seu próprio motivo. O AccountService só muda quando o fluxo de criação de conta muda.

flowchart LR
    subgraph bad ["❌ Antes — uma classe, muitas preocupações"]
        as["AccountService\n• validar\n• persistir\n• enviar e-mail\n• auditar"]
    end
    subgraph good ["✅ Depois — uma classe por preocupação"]
        direction TB
        as2["AccountService\n(orquestrar)"]
        r["AccountRepository\n(persistir)"]
        e["EmailService\n(notificar)"]
        a["AuditService\n(registrar)"]
        as2 --> r & e & a
    end

O — Princípio Aberto/Fechado

"Entidades de software devem estar abertas para extensão, mas fechadas para modificação." — Bertrand Meyer

Um módulo é aberto se pode ser estendido com novo comportamento. É fechado se o seu código-fonte é estável — os consumidores e testes existentes não quebram quando um novo comportamento é adicionado. O mecanismo é a abstração: defina uma interface da qual quem chama depende e, depois, adicione novas implementações sem mexer em quem chama.

Violação

Aplicado — interface

Aplicado — serviço

DiscountService.java — modified for every new type
// VIOLATION: every new customer type requires modifying this class.
// The class is open for modification but closed for extension.
public class DiscountService {

    public double calculate(Account account) {
        if ("VIP".equals(account.type())) {
            return account.orderTotal() * 0.20;
        } else if ("EMPLOYEE".equals(account.type())) {
            return account.orderTotal() * 0.30;
        } else if ("SEASONAL".equals(account.type())) {
            // Added later — had to reopen this class
            return account.orderTotal() * 0.15;
        } else {
            return account.orderTotal() * 0.05;
        }
        // Adding "PARTNER" requires another else-if and another class modification.
    }
}

DiscountPolicy.java — extension point
// Extension point: implement this interface to add a new discount rule
// without touching DiscountService.
public interface DiscountPolicy {
    boolean appliesTo(Account account);
    double calculate(Account account);
}

DiscountService.java — closed for modification
// Closed for modification: this class never changes when a new policy is added.
// Open for extension: inject a new DiscountPolicy implementation.
public class DiscountService {

    private final List<DiscountPolicy> policies;

    public DiscountService(List<DiscountPolicy> policies) {
        this.policies = policies;
    }

    public double calculate(Account account) {
        return policies.stream()
            .filter(p -> p.appliesTo(account))
            .findFirst()                                // same rule as before: one policy applies
            .map(p -> p.calculate(account))
            .orElse(account.orderTotal() * 0.05);       // default discount
    }
}

// Each policy is a new class — DiscountService is never touched again.
class VipDiscountPolicy implements DiscountPolicy {
    public boolean appliesTo(Account a) { return "VIP".equals(a.type()); }
    public double calculate(Account a)  { return a.orderTotal() * 0.20; }
}

class EmployeeDiscountPolicy implements DiscountPolicy {
    public boolean appliesTo(Account a) { return "EMPLOYEE".equals(a.type()); }
    public double calculate(Account a)  { return a.orderTotal() * 0.30; }
}

classDiagram
    class DiscountService {
        +calculate(account) double
    }
    class DiscountPolicy {
        <<interface>>
        +appliesTo(account) bool
        +calculate(account) double
    }
    class VipDiscountPolicy
    class EmployeeDiscountPolicy
    class PartnerDiscountPolicy

    DiscountService --> DiscountPolicy
    VipDiscountPolicy ..|> DiscountPolicy
    EmployeeDiscountPolicy ..|> DiscountPolicy
    PartnerDiscountPolicy ..|> DiscountPolicy

Adicionar PartnerDiscountPolicy exige criar uma única classe nova — o DiscountService nunca é tocado. No Spring, basta anotar cada política com @Component: o container injeta todos os beans DiscountPolicy no parâmetro List<DiscountPolicy> do construtor.

Fechado contra quais mudanças?

Nenhuma classe é fechada contra todas as mudanças. O OCP pede que você antecipe o eixo provável de variação (aqui: novos tipos de cliente) e coloque a abstração ali. Adicionar pontos de extensão "por via das dúvidas" produz interfaces com uma única implementação para sempre.

L — Princípio da Substituição de Liskov

"Se S é um subtipo de T, então objetos do tipo T podem ser substituídos por objetos do tipo S sem alterar nenhuma das propriedades desejáveis do programa." — a paráfrase usual de Barbara Liskov (1987) e de Liskov & Wing (1994)

Todo subtipo precisa honrar o contrato do supertipo — não apenas as assinaturas dos métodos, mas o comportamento. Um código que funciona corretamente com T precisa funcionar corretamente com qualquer S extends T, sem modificações.

Violação — Square extends Rectangle

Aplicado — interface comum

Rectangle.java / Square.java — contract broken
public class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int w)  { this.width  = w; }
    public void setHeight(int h) { this.height = h; }
    public int area()            { return width * height; }
}

// VIOLATION: Square overrides setters in a way that breaks Rectangle's contract.
// Client code that sets width and height independently will get wrong results.
public class Square extends Rectangle {

    @Override
    public void setWidth(int w) {
        this.width  = w;
        this.height = w; // forces both dimensions to be equal
    }

    @Override
    public void setHeight(int h) {
        this.width  = h; // forces both dimensions to be equal
        this.height = h;
    }
}

// Client code expecting Rectangle behaviour:
// rect.setWidth(5);   rect.setHeight(3);
// assert rect.area() == 15;   ← FAILS for Square: area() returns 9

Shape.java — subtypes honour the contract
// Proper design: both share a common interface without inheritance between them.
// Each type upholds its own contract independently.
public interface Shape {
    int area();
}

public class Rectangle implements Shape {
    private final int width;
    private final int height;

    public Rectangle(int width, int height) {
        this.width  = width;
        this.height = height;
    }

    @Override
    public int area() { return width * height; }
}

public class Square implements Shape {
    private final int side;

    public Square(int side) { this.side = side; }

    @Override
    public int area() { return side * side; }
}

// Any code expecting a Shape can use Rectangle or Square interchangeably.
// No surprises — each type fulfils the Shape contract correctly.

classDiagram
    class Shape {
        <<interface>>
        +area() int
    }
    class Rectangle {
        -width int
        -height int
        +area() int
    }
    class Square {
        -side int
        +area() int
    }
    Rectangle ..|> Shape
    Square ..|> Shape

LSP e testes

Um teste prático: se substituir por um subtipo faz falhar um teste escrito para o supertipo, o subtipo viola o LSP. É por isso que uma suíte de testes escrita contra uma interface (Shape) precisa passar para todas as implementações.

LSP na loja: adaptadores de teste

O InMemoryAccountRepository (usado nos testes unitários) e o AccountJpaAdapter (usado em produção) implementam AccountRepository. Se o banco de dados rejeita um e-mail duplicado por meio de uma restrição UNIQUE, mas a versão em memória o sobrescreve silenciosamente, os dois não são substituíveis: os testes unitários passam e a produção falha. Mantenha idêntico em todas as implementações o comportamento que a porta promete — não só as assinaturas dos métodos —, de preferência rodando um único teste de contrato compartilhado contra as duas.

I — Princípio da Segregação de Interfaces

"Clientes não devem ser forçados a depender de interfaces que não usam." — Robert C. Martin

Uma interface "gorda" obriga os clientes a declarar dependências de métodos que nunca chamam. Quando esses métodos mudam — por motivos que nada têm a ver com o cliente —, o cliente precisa ser recompilado e implantado de novo. Interfaces menores e focadas minimizam o acoplamento.

Violação — interface gorda

Aplicado — segregada

AccountRepository.java — fat interface
// VIOLATION: a single fat interface mixes read, write, admin, and reporting.
// Clients that only read data are forced to depend on write and admin methods.
public interface AccountRepository {

    // Read operations
    Optional<Account> findById(String id);
    Optional<Account> findByEmail(String email);
    List<Account> findAll();

    // Write operations
    Account save(Account account);
    void delete(String id);

    // Admin operations — not needed by most clients
    List<Account> findByRole(String role);
    void bulkImport(List<Account> accounts);

    // Reporting — not needed by most clients
    Map<String, Long> countByRegion();
    List<Account> findInactive(Duration since);
}

// A read-only client (e.g. a profile page service) now depends on all nine methods:
// a change to bulkImport() or countByRegion() affects it, and any test fake of this
// interface must stub write, admin and reporting methods it never calls.

AccountReader / AccountWriter / AccountAdmin
// Segregated interfaces: each client depends only on what it actually uses.

public interface AccountReader {
    Optional<Account> findById(String id);
    Optional<Account> findByEmail(String email);
    List<Account> findAll();
}

public interface AccountWriter {
    Account save(Account account);
    void delete(String id);
}

public interface AccountAdmin extends AccountReader {
    List<Account> findByRole(String role);
    void bulkImport(List<Account> accounts);
}

// AccountService depends only on what it needs — no unused methods.
public class AccountService {
    private final AccountReader reader;
    private final AccountWriter writer;

    public AccountService(AccountReader reader, AccountWriter writer) {
        this.reader = reader;
        this.writer = writer;
    }

    public Account findById(String id) {
        return reader.findById(id).orElseThrow(AccountNotFoundException::new);
    }

    public Account save(Account account) {
        return writer.save(account);
    }
}

// The JPA adapter implements all interfaces — no behaviour is lost.
class JpaAccountAdapter implements AccountReader, AccountWriter, AccountAdmin {
    // single implementation, multiple interfaces
}

classDiagram
    class AccountReader {
        <<interface>>
        +findById(id)
        +findByEmail(email)
        +findAll()
    }
    class AccountWriter {
        <<interface>>
        +save(account)
        +delete(id)
    }
    class AccountAdmin {
        <<interface>>
        +findByRole(role)
        +bulkImport(accounts)
    }
    AccountAdmin --|> AccountReader
    class JpaAccountAdapter
    JpaAccountAdapter ..|> AccountReader
    JpaAccountAdapter ..|> AccountWriter
    JpaAccountAdapter ..|> AccountAdmin

    class AccountService {
        -reader AccountReader
        -writer AccountWriter
    }
    AccountService --> AccountReader
    AccountService --> AccountWriter

O AccountService depende apenas de AccountReader e AccountWriter. Mudanças nos métodos de administração ou de relatórios nunca o afetam.

D — Princípio da Inversão de Dependência

"Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações." — Robert C. Martin

Sem o DIP, a lógica de negócio de alto nível (os casos de uso) conhece e instancia a infraestrutura de baixo nível (bancos de dados, clientes HTTP). Uma mudança no banco de dados força a reescrita da lógica de negócio. O DIP inverte isso: o módulo de alto nível declara uma interface (a abstração) e o módulo de baixo nível a implementa. Ambos dependem da interface — a seta de dependência aponta para a regra de negócio, não para a infraestrutura.

Violação — instanciação direta

Aplicado — depende de abstração

AccountService.java — tightly coupled to MySql
// VIOLATION: high-level module directly instantiates a low-level module.
// Swapping the persistence mechanism requires modifying AccountService.
public class AccountService {

    // Direct dependency on a concrete class — impossible to substitute in tests
    private final MySqlAccountRepository repository = new MySqlAccountRepository();

    public Account findById(String id) {
        return repository.findById(id);
    }

    public Account create(AccountIn in) {
        Account account = Account.of(in);
        repository.save(account);
        return account;
    }
}

// Concrete low-level module
class MySqlAccountRepository {
    public Account findById(String id) { /* SQL query */ return null; }
    public void save(Account account)  { /* SQL insert */ }
}

AccountService.java + AccountRepository + JpaAccountRepository
// Abstraction — defined by the high-level module, implemented by the low-level module.
public interface AccountRepository {
    Optional<Account> findById(String id);
    Account save(Account account);
}

// High-level module depends on the abstraction, not on a concrete class.
// The implementation is injected at runtime by the DI container (Spring).
public class AccountService {

    private final AccountRepository repository;

    public AccountService(AccountRepository repository) {
        this.repository = repository;
    }

    public Account findById(String id) {
        return repository.findById(id)
            .orElseThrow(AccountNotFoundException::new);
    }

    public Account create(AccountIn in) {
        return repository.save(Account.of(in));
    }
}

// Low-level module also depends on the abstraction.
@Repository
public class JpaAccountRepository implements AccountRepository {

    private final AccountJpaRepository jpa;

    public JpaAccountRepository(AccountJpaRepository jpa) {
        this.jpa = jpa;
    }

    @Override
    public Optional<Account> findById(String id) {
        return jpa.findById(id).map(AccountMapper::toDomain);
    }

    @Override
    public Account save(Account account) {
        return AccountMapper.toDomain(jpa.save(AccountMapper.toTable(account)));
    }
}

flowchart LR
    subgraph bad ["❌ Antes"]
        as_bad["AccountService"] -->|new| mysql["MySqlAccountRepository"]
    end
    subgraph good ["✅ Depois"]
        as_good["AccountService"] -->|depende de| iface["«interface»\nAccountRepository"]
        jpa["JpaAccountRepository"] -->|implementa| iface
        memory["InMemoryAccountRepository\n(teste)"] -->|implementa| iface
    end

Repare em quem é dono da interface: AccountRepository é declarada ao lado do AccountService (o módulo de alto nível), em termos de negócio, e a classe JPA a implementa. Se a interface ficasse no pacote de persistência e espelhasse o JPA, a dependência não estaria de fato invertida.

O DIP (um princípio de projeto) é frequentemente confundido com dois mecanismos relacionados:

Injeção de Dependência (Dependency Injection) — uma técnica: os objetos recebem as suas dependências (normalmente pelo construtor) em vez de criá-las com new. O container do Spring faz isso para todo @Service, @Repository e @Component.
Inversão de Controle (Inversion of Control) — a ideia geral de que um framework chama o seu código (e o conecta), em vez de o seu código chamar o framework.

A Injeção de Dependência é a forma como o DIP costuma ser implementado no Spring, mas injetar uma classe concreta ainda acopla você a ela; o DIP exige que o tipo injetado seja uma abstração que pertence ao módulo de alto nível.

O DIP é o princípio que torna possíveis a Clean Architecture e a Arquitetura Hexagonal: ao inverter as dependências em cada fronteira entre camadas, cada camada pode ser desenvolvida, testada e substituída de forma independente.

Resumo

Princípio	Problema resolvido	Mecanismo
SRP	Classes que mudam por vários motivos quebram quem não tem nada a ver com a mudança	Uma preocupação por classe
OCP	Modificar código existente para adicionar funcionalidades quebra o comportamento existente	Estender por meio de novas implementações de uma interface
LSP	Subtipos que quebram os contratos do supertipo causam bugs sutis em tempo de execução	Honrar contratos de comportamento, não só assinaturas de métodos
ISP	Interfaces gordas obrigam quem chama a depender de métodos que não usa	Dividir as interfaces de acordo com a necessidade do cliente
DIP	Lógica de alto nível acoplada à infraestrutura de baixo nível	Ambos dependem de uma abstração; os detalhes dependem das políticas

SOLID é um guia, não um objetivo

Uma interface para cada classe. Uma interface com exatamente uma implementação e nenhum dublê de teste só acrescenta um arquivo e mais nada. Introduza a abstração quando surgir uma segunda implementação (ou um fake de teste).
SRP levado a um método por classe. Dividir demais espalha um conceito de negócio por dez arquivos; divida pelo motivo para mudar, não pela quantidade de linhas.
Herança para reaproveitar código. A maioria das violações do LSP vem de extends usado para compartilhar código; prefira composição e interfaces pequenas.
Generalidade especulativa. Princípios aplicados a requisitos futuros imaginários produzem uma complexidade que você paga hoje (YAGNI — You Aren't Gonna Need It, "você não vai precisar disso").

Pontos-chave

O SOLID trata de gerenciar mudanças: cada princípio limita o quanto uma mudança em um lugar se propaga pelo código.
SRP: um motivo para mudar (um ator) por classe. OCP: adicione comportamento adicionando classes atrás de uma interface.
LSP: subtipos e implementações precisam manter o comportamento do contrato — incluindo dublês de teste e adaptadores.
ISP: dê a cada cliente uma interface pequena, só com o que ele usa. DIP: o código de negócio é dono das interfaces; a infraestrutura as implementa.
DIP + injeção de dependência é a ponte para a Clean Architecture e a Arquitetura Hexagonal, em que as mesmas ideias são aplicadas ao serviço inteiro.

MARTIN, R. C. Agile Software Development: Principles, Patterns, and Practices. Pearson, 2002. ↩
MEYER, B. Object-Oriented Software Construction, 1st ed. Prentice Hall, 1988. ↩
LISKOV, B.; WING, J. A Behavioral Notion of Subtyping. ACM TOPLAS, 1994. ↩
MARTIN, R. C. The Single Responsibility Principle. The Clean Code Blog, 2014. ↩