📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Módulo 10: Paradigmas e Padrões de Projeto. Recomendado revisar antes de começar.
v1.0 — Factory Method, Strategy, Decorator, Observer e Princípios SOLID
Trilha de Especialização Pedagógica — Projeto 1 de 4
- ➡️ v1 (este): Padrões GoF Criacionais, Estruturais e Comportamentais · SOLID
- v2: Repository Pattern & Unit of Work Enterprise
- v3: Specification Pattern & Chain of Responsibility
- v4: Event Sourcing & CQRS Architecture
🎓 Nível Profissional Simulado: Engenheiro de Software Pleno. Código amador usa dezenas de
if/elseeswitch/caseespalhados para decidir regras de negócio. Um engenheiro experiente aplica os Padrões de Projeto GoF, tornando o código extensível, modular e imune a quebras quando novos provedores são adicionados.
—`
Construir um Gateway de Pagamentos Corporativo aplicando os padrões Strategy (para alternância de meios de pagamento Pix, Cartão e Boleto), Factory Method (para instanciação desacoplada), Decorator (para injeção transparente de logs de auditoria e métricas) e Observer (para notificações de confirmação de pagamento).
—`
“Nosso e-commerce aceita apenas Cartão de Crédito com um código cheio de ifs acoplados. Precisamos aceitar Pix e Boleto sem reescrever o checkout, queremos que cada transação registre logs de auditoria automaticamente sem poluir a regra de negócio do pagamento, e precisamos notificar o cliente por e-mail quando a compra for confirmada.”
| ID | Tipo | Descrição | Origem no Briefing |
|---|---|---|---|
| RF01 | Funcional | Suportar múltiplos métodos de pagamento intercambiáveis (Pix, Cartão, Boleto). | “aceitar Pix e Boleto sem reescrever” |
| RF02 | Funcional | Adicionar camada transparente de auditoria e logging em todas as transações. | “registre logs de auditoria” |
| RF03 | Funcional | Notificar sistemas externos (E-mail, BI) via eventos após confirmação. | “notificar o cliente por e-mail” |
| RNF01 | Não-Funcional | Princípio Aberto/Fechado (OCP): adicionar novo método sem alterar classes existentes. | Arquitetura SOLID |
| RNF02 | Não-Funcional | Inversão de Dependência (DIP): depender de abstrações (MetodoPagamento). |
Arquitetura SOLID |
—`
| ID | User Story | Prioridade |
|---|---|---|
| US01 | Como cliente, quero pagar via Pix recebendo QR Code com processamento auditado. | Alta |
| US02 | Como arquiteto, quero plugar novos adquirentes sem alterar a classe de Checkout. | Alta |
—`
# Branch da funcionalidade
git checkout -b feature/US01-gof-payment-gateway
# Executar a suíte de pagamentos
python src/gateway_core.py
—`
src/gateway_core.py)class PagamentoFactory:
@staticmethod
def criar(tipo: str) -> MetodoPagamento:
if tipo.lower() == "pix":
return PagamentoComAuditoria(PagamentoPix())
elif tipo.lower() == "cartao":
return PagamentoComAuditoria(PagamentoCartao())
raise ValueError(f"Metodo de pagamento nao suportado: {tipo}")
—`
No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:
cd padroes_01_gateway_pagamentos_gof
# Executar comandos específicos da tecnologia:
python main.py # ou npm run dev / ./gradlew build
[!TIP] Dica para execução a partir da raiz do repositório: Se você abriu o repositório completo no VS Code, basta navegar até a pasta antes de executar: cd proj_aplicacoes_full_stack/projetos/padroes_01_gateway_pagamentos_gof`
—`
pix = PagamentoFactory.criar("pix")
assert pix.processar(100.0) == True
—`
- Padrões Strategy, Factory Method e Decorator funcionando harmonicamente.
- Novos métodos podem ser adicionados criando apenas uma nova subclasse.
| ⬅️ Ver Todos os Projetos no Super-Hub | 🏠 Página Inicial do Portal |