SOLID: Interface Segregation Principle (Parte 3)

O “I” do SOLID

O Interface Segregation Principle (ISP) costuma ser resumido assim:

Ninguém deve ser forçado a depender de métodos que não usa.

Isso combina muito com o que vimos no LSP (Parte 2): contratos honestos evitam “implementações mentirosas”.

O sintoma mais comum: “DeusInterface”

Você cria uma interface gigante (um UserRepositoryInterface com CRUD completo, buscas específicas, exportação, auditoria, cache…) e tenta fazer o mundo inteiro implementar aquilo. O resultado é previsível: metade dos métodos vira throw new Exception('not implemented') ou implementação vazia.

Isso é cheiro forte de violação de ISP (e também de LSP, dependendo do caso).

Exemplo na prática: segregar contratos

Ruim: um contrato gigante

<?php

declare(strict_types=1);

interface UserModuleInterface
{
    public function authenticate(string $email, string $password): bool;

    public function register(array $data): int;

    public function exportCsv(): string;

    public function sendWelcomeEmail(int $userId): void;
}

Explicação: um componente que só autentica não deveria “enxergar” exportação CSV.

Melhor: interfaces coesas

<?php

declare(strict_types=1);

interface Authenticator
{
    public function authenticate(string $email, string $password): bool;
}

interface UserRegistrar
{
    public function register(UserDraft $draft): UserId;
}

interface UserExporter
{
    public function toCsv(): string;
}

interface Notifier
{
    public function sendWelcome(UserId $id): void;
}

Explicação: cada cliente depende só do que precisa. Você ainda pode ter uma classe concreta que implementa várias interfaces, mas o acoplamento fica no lugar certo.

ISP não é “1 método por interface”

Segregar demais também custa: explode arquivos, dificulta navegação e pode virar ruído.

Bom critério: coesão de uso, “quem chama isso junto?” e “quem precisa disso separado?”.

Relação com arquitetura

ISP aparece muito ao desenhar ports (Ports & Adapters): portas pequenas costumam envelhecer melhor do que “API única do sistema”.

Conclusão

ISP é sobre dependências mínimas e significativas. Menos força implementações a mentir; mais clareza sobre papéis.