Síntese Arquitetural: Núcleo Estável, Periferia Volátil e o Encerramento do Curso

Aula 14 — Programação Orientada a Objetos (Aula de Encerramento)

Autor

Marcos M. Raimundo — Instituto de Computação, UNICAMP

Data de Publicação

18 de setembro de 2026

1 Proposta da Aula

Nas últimas quatro aulas, o Pedido que atravessa esta disciplina ganhou um repertório de quatro padrões de projeto — Strategy (Aula 10), Adapter (Aula 12), Decorator e Observer (Aula 13) —, cada um resolvendo um problema concreto de acoplamento. Esta é a última aula nova do curso, e ela não introduz um quinto padrão. Em vez disso, dá um passo para trás e pergunta: o que esses quatro padrões têm, estruturalmente, em comum?

A resposta é uma única ideia arquitetural, repetida quatro vezes com sotaques diferentes: todo sistema de software saudável separa um núcleo estável — os contratos, as interfaces, as regras de negócio que raramente mudam — de uma periferia volátil — as implementações concretas, os SDKs de terceiros, os detalhes de infraestrutura que mudam por pressão do mercado. Strategy, Adapter, Decorator e Observer são quatro formas diferentes de erguer essa mesma fronteira, cada uma respondendo a um tipo específico de instabilidade.

O roteiro desta aula, em três perguntas:

O que exatamente separa o “lado estável” do “lado volátil” de um sistema, e por que a direção da dependência entre eles importa mais do que a quantidade de código em cada lado?
Colocando Strategy, Adapter, Decorator e Observer lado a lado numa mesma matriz, que tipo específico de acoplamento nocivo cada um deles ataca — e por que nenhum dos quatro resolve o problema dos outros três?
Voltando à primeira aula deste curso: os quatro padrões, tomados em conjunto, são de fato uma resposta madura ao problema original do custo de mudança e ao acrônimo TRUE — mas de que forma exatamente?

Problema motivador: pense nas quatro aulas anteriores como quatro histórias independentes — uma explosão de if/else (Strategy), um SDK de terceiros com assinatura incompatível (Adapter), uma explosão combinatória de subclasses (Decorator), uma cascata de chamadas diretas a serviços (Observer). Elas parecem problemas diferentes. O que este fechamento revela é que, arquiteturalmente, são o mesmo problema visto de quatro ângulos.

2 Fronteiras Arquiteturais: Núcleo Estável e Periferia Volátil

O conceito de parede de proteção. Padrões de projeto não servem apenas para organizar código; eles estabelecem linhas de demarcação estritas dentro do sistema. Uma arquitetura de software saudável divide qualquer sistema, sem ambiguidade, em duas regiões: o lado estável e o lado volátil.

O lado estável é o Núcleo (Core): contratos, interfaces, as regras de negócio mais abstratas do sistema. Essa camada muda muito raramente, porque ela define o que a aplicação faz em termos lógicos — não como ela faz. O lado volátil é a Periferia: os detalhes técnicos de implementação — queries de banco de dados, protocolos de rede, algoritmos sujeitos a alterações sazonais, bibliotecas de terceiros. Ela muda com frequência, porque responde a pressões externas ao domínio do negócio (um banco troca de fornecedor de gateway de pagamento; a lei muda uma alíquota de imposto; um serviço de e-mail é substituído por outro).

A introdução sistemática de interfaces — exatamente o que Strategy, Adapter, Decorator e Observer fazem, cada um a seu modo — funciona como uma junta de dilatação: quando erguemos uma fronteira usando qualquer um desses padrões, garantimos que os tremores causados por mudanças na periferia volátil (a troca de um SDK de pagamento, a alteração de uma alíquota) morram na barreira do contrato, sem se propagar para dentro do núcleo. Isso é uma generalização direta de dois princípios que este curso já formalizou separadamente: o DIP (Aula 5) e o OCP (Aula 10). A Regra de Ouro que resume essa fronteira é simples de enunciar e difícil de romper na prática:

“O código estável nunca deve depender do código volátil. A dependência deve apontar sempre para as abstrações.”

Note que a regra fala de direção, não de proporção. Não importa se a periferia tem mais linhas de código que o núcleo — o que importa é para onde apontam as setas de dependência no grafo do sistema. Um módulo de alto nível (estável) nunca conhece diretamente um módulo de baixo nível (volátil); ambos dependem de uma abstração intermediária, e é essa abstração — não o núcleo, não a periferia — que absorve o impacto da mudança.

O diagrama a seguir mostra essa topologia de forma genérica: um núcleo estável envolto por uma camada de abstração (a “parede”), com quatro exemplos de periferia volátil (um SDK de pagamento, um banco de dados, um serviço de e-mail, um algoritmo sazonal de frete) apontando para dentro da parede — nunca o núcleo apontando para fora dela.

A borda tracejada representa a camada de abstração (a “parede”): cada elemento da periferia (vermelho) aponta para dentro dela — implementa o contrato que ela define —, mas o núcleo (azul, no centro) nunca precisa apontar para fora. Se o banco de dados for trocado, ou o SDK de pagamento for substituído por outro fornecedor, a seta que muda é a da periferia; o núcleo permanece intocado.

Se a troca do banco de dados relacional de um sistema por um banco NoSQL não exigir nenhuma alteração de código na camada de regras de negócio, o que isso revela sobre como a fronteira entre núcleo e periferia foi desenhada — e onde exatamente mora essa fronteira?

Escreva sua resposta e compare com um colega antes de avançar (2 min).

□ Se um sistema trocar seu banco de dados relacional por um banco NoSQL sem que nenhuma classe da camada de regras de negócio precise ser recompilada, isso é evidência de que a fronteira entre o núcleo estável e a periferia volátil foi desenhada corretamente nesse ponto do sistema.
□ Se a interface usada para acessar um gateway de pagamento externo for definida dentro do próprio pacote do gateway (e não dentro do núcleo do sistema que o consome), a Regra de Ouro da dependência ainda estaria sendo respeitada, desde que o núcleo apenas implemente essa interface.
□ Mesmo em um sistema hipotético sem nenhuma dependência de infraestrutura externa (sem banco de dados, sem SDKs, sem rede), ainda pode haver periferia volátil dentro do próprio código — por exemplo, um algoritmo de cálculo de frete sujeito a mudanças sazonais frequentes.
□ Como o núcleo estável é definido por conter as regras de negócio do sistema, qualquer classe que implemente uma fórmula de cálculo (como uma fórmula de imposto) deve necessariamente pertencer ao núcleo estável, nunca à periferia volátil.

3 Matriz Comparativa de Decisão: os Quatro Padrões

Uma matriz para escolher a ferramenta certa. O domínio da sintaxe de cada padrão precisa ser acompanhado pelo discernimento arquitetural de saber exatamente quando aplicar cada estrutura. A tabela a seguir consolida, lado a lado, a intenção principal e o critério de aplicação de Strategy, Adapter, Decorator e Observer — os quatro padrões estudados nesta disciplina.

Matriz de decisão arquitetural para padrões de isolamento.
Padrão	Intenção principal	Quando utilizar
Strategy (Aula 10)	Isolar famílias de algoritmos intercambiáveis a partir de uma mesma interface.	Quando o comportamento lógico de um método varia com base no contexto ou em regras de mercado voláteis (ex.: cálculo de impostos ou fretes).
Adapter (Aula 12)	Converter a interface de uma classe existente em outra interface esperada pelo cliente.	Ao integrar o sistema a componentes externos cujo contrato de código não pode ser modificado (ex.: SDK de bancos ou frameworks legados).
Decorator (Aula 13)	Anexar responsabilidades adicionais a um objeto de maneira dinâmica e cumulativa.	Quando a expansão de funcionalidades por herança estática geraria uma explosão combinatória de subclasses (ex.: opcionais de produtos).
Observer (Aula 13)	Criar um vínculo um-para-muitos em que a mudança de estado de um objeto aciona dependentes anonimamente.	Quando a execução de um fluxo principal de negócio precisa disparar reações em múltiplos subsistemas independentes.

A análise detalhada da tabela revela que cada padrão ataca um tipo específico de acoplamento nocivo — e é exatamente por isso que nenhum dos quatro substitui os outros três:

O Strategy elimina o acoplamento condicional — a cadeia de if/else que testava explicitamente qual algoritmo aplicar.
O Adapter sana o acoplamento sintático — a incompatibilidade de assinatura entre o contrato que o sistema espera e o contrato que uma biblioteca externa oferece.
O Decorator soluciona o acoplamento taxonômico — a rigidez de uma árvore de herança fixada em tempo de compilação, incapaz de representar combinações decididas em tempo de execução.
O Observer erradica o acoplamento temporal e de identidade — a necessidade de um objeto conhecer, por nome e no momento exato do evento, cada um dos subsistemas que precisam reagir a ele.

Compreender essa matriz — não apenas a mecânica de cada padrão isoladamente — é o que transforma um desenvolvedor que escreve código correto num modelador de sistemas resilientes: a pergunta deixa de ser “eu sei implementar Strategy?” e passa a ser “este sintoma de acoplamento que estou vendo agora é condicional, sintático, taxonômico ou temporal — e, portanto, qual padrão o resolve?”.

Vale reforçar, com um cenário concreto: se um Pedido precisa (a) escolher entre três meios de pagamento com a mesma assinatura de método (Strategy), (b) integrar um desses meios de pagamento a um SDK legado com assinatura incompatível (Adapter), (c) acumular selos de fidelidade opcionais sobre o pedido fechado (Decorator), e (d) notificar um número variável de sistemas de log e estoque quando o pedido é faturado (Observer) — os quatro padrões coexistem tranquilamente na mesma classe Pedido, porque cada um resolve um problema estrutural diferente dos outros três, não uma versão redundante do mesmo problema.

O diagrama a seguir sintetiza essa ideia: os quatro padrões como quatro “paredes” diferentes ao redor do mesmo núcleo (Pedido), cada uma endereçando um tipo de volatilidade que nenhuma das outras três resolve.

As quatro setas partem do mesmo núcleo, mas cada uma atravessa uma “parede” de natureza diferente — não há sobreposição de responsabilidade entre elas, e é justamente essa ausência de sobreposição que permite aos quatro padrões coexistirem na mesma classe sem conflito.

Se um engenheiro precisa, ao mesmo tempo, trocar o algoritmo de cálculo de frete conforme a transportadora e notificar um número variável de sistemas externos sempre que um pedido é despachado, quantos padrões diferentes desta matriz ele provavelmente precisa combinar — e por que isso não contradiz a ideia de que cada padrão ataca um tipo específico de acoplamento?

Escreva sua resposta e compare com um colega antes de avançar (2 min).

□ Como Strategy e Adapter compartilham a mesma topologia estrutural básica (uma interface e implementações concretas injetadas por composição), eles resolvem exatamente o mesmo tipo de problema de acoplamento, apenas com nomes históricos diferentes.
□ Um sistema que precisa oferecer suporte simultâneo a três gateways de pagamento com assinaturas de método incompatíveis entre si, mantendo uma única interface interna de cobrança, está diante de um cenário mais bem resolvido por Adapter do que por Strategy.
□ Se um PedidoSubject tivesse apenas um único observador registrado, e esse número nunca mudasse ao longo de toda a vida do sistema, aplicar o padrão Observer ainda traria o benefício estrutural de o núcleo não conhecer o tipo concreto desse observador, mesmo sem nenhum ganho vindo da quantidade de assinantes.
□ Já que Decorator e Observer resolvem problemas relacionados a decisões tomadas em tempo de execução, um sistema que já usa Decorator para acumular responsabilidades sobre um Pedido nunca precisaria também aplicar Observer para notificar múltiplos subsistemas sobre esse mesmo Pedido.

4 Conclusão

Voltando às três perguntas da abertura:

O que separa o lado estável do lado volátil, e por que a direção da dependência importa mais que a proporção: o núcleo (contratos, regras de negócio abstratas) muda raramente; a periferia (implementações concretas, infraestrutura, SDKs) muda por pressão externa. A Regra de Ouro exige que a dependência aponte sempre para a abstração — nunca do estável para o volátil —, generalizando o DIP e o OCP já vistos separadamente nas Aulas 5 e 10.
O que a matriz revela sobre os quatro padrões: cada um ataca um tipo específico de acoplamento — Strategy (condicional), Adapter (sintático), Decorator (taxonômico), Observer (temporal/identidade) — e por isso nenhum substitui os outros três; problemas reais frequentemente exigem combiná-los na mesma classe.
Como os quatro padrões respondem ao problema original da Aula 1: cada um deles é uma forma concreta de tornar o código mais Transparente (as consequências de trocar uma implementação ficam contidas na periferia), mais Razoável (o custo de adicionar uma nova variação — um novo meio de pagamento, um novo observador — é proporcional ao benefício, não uma reescrita), mais Usável (o núcleo pode ser reaproveitado com periferias diferentes, como o Pedido sendo usado com qualquer Pagavel) e mais Exemplar (a fronteira estável/volátil, uma vez estabelecida, convida quem mantém o código a preservá-la, não a corroê-la).

Encerramento da disciplina. Este curso começou com uma pergunta simples — como escrever software que sobrevive à mudança? — e com um diagnóstico de que sistemas mal projetados têm um custo de manutenção que cresce exponencialmente, não linearmente. Catorze aulas depois, a resposta não é uma técnica única, é um hábito de pensamento: perguntar, diante de qualquer decisão de design, “o que aqui é estável, e o que aqui é volátil — e minha dependência está apontando na direção certa?”. A máquina de estados da Aula 2, os contratos e a Lei de Demeter da Aula 3, a decomposição por responsabilidade da Aula 4, as métricas de acoplamento e o DIP da Aula 5, as interfaces como contrato puro da Aula 6, o polimorfismo e o LSP das Aulas 7–9, e os quatro padrões das Aulas 10–13 são, todos, instâncias diferentes da mesma disciplina de pensamento: isolar o que muda pouco daquilo que muda muito, e deixar que só a abstração atravesse essa fronteira.

O software profissional, nesse sentido, funciona como um organismo vivo ou como um computador de mesa bem projetado: os órgãos não espiam o estado celular uns dos outros, e uma placa-mãe estável aceita qualquer placa de vídeo ou memória do mercado, desde que o componente periférico respeite o formato do encaixe. Projetar bem não é escrever código que nunca muda — é escrever código cujas mudanças ficam contidas exatamente onde deveriam ficar. Essa é a nota final deste curso: TRUE não é um acrônimo para ser lembrado em uma prova, é o critério prático por trás de cada padrão, cada princípio e cada linha de código que esta disciplina construiu ao longo do semestre.

Exercícios Soluções