🔌 Padrão de Projeto Adapter - Sistema de Pagamentos

Um exemplo prático e educativo de como integrar sistemas legados com interfaces modernas utilizando o Design Pattern Adapter.

---

📌 Visão Geral

Este projeto simula um cenário comum no desenvolvimento de software: a necessidade de integrar um sistema de pagamentos moderno (Stripe) com um sistema bancário legado, onde as interfaces são incompatíveis.

O código demonstra duas abordagens:

1. ❌ Sem Adapter: Alto acoplamento e lógica de conversão misturada na classe principal.
2. ✅ Com Adapter: Uso do padrão para encapsular a conversão, mantendo o princípio SOLID (Open/Closed).

---

🏗️ Arquitetura (Diagrama)

O padrão Adapter permite que classes com interfaces incompatíveis trabalhem juntas.

classDiagram
    class PaymentProcessor {
        +process_payment()
    }
    class PaymentTarget {
        <<interface>>
        +pay(amount, currency, description)
    }
    class BankAdapter {
        +pay(amount, currency, description)
    }
    class LegacyBankPayment {
        +pay(value, currency_code, payment_reason)
    }
    
    PaymentProcessor --> PaymentTarget
    BankAdapter ..|> PaymentTarget
    BankAdapter --> LegacyBankPayment : Adapta

Loading

---

📁 Estrutura do Projeto

Adapter-Design-Pattern/
├── Padrão de Projeto Adapter/
│   ├── Implementação com o Padrão Adapter.py   # Solução limpa e desacoplada
│   └── Implementação sem o Padrão Adapter.py   # Exemplo do problema (acoplado)
├── LICENSE                                     # Licença (Public Domain)
└── README.md                                   # Documentação

---

📋 Cenário do Problema

O sistema precisa processar pagamentos usando dois provedores com assinaturas de métodos completamente diferentes:

Provedor	Classe	Método	Assinatura
Moderno	StripePayment	make_payment	(amount, currency, description)
Legado	LegacyBankPayment	pay	(value, currency_code, payment_reason)

---

🚀 Como Executar

Certifique-se de ter o Python instalado. Como os nomes dos arquivos contêm espaços, utilize aspas ao executar no terminal:

1. Clone o repositório:

git clone [https://github.com/oliverws7/adapter-design-pattern.git](https://github.com/oliverws7/adapter-design-pattern.git)
cd adapter-design-pattern

2. Execute a versão SEM o padrão (Observe o acoplamento):

python "Padrão de Projeto Adapter/Implementação sem o Padrão Adapter.py"

3. Execute a versão COM o padrão Adapter (Solução Ideal):

python "Padrão de Projeto Adapter/Implementação com o Padrão Adapter.py"

---

⚖️ Análise Comparativa

Critério	Sem Adapter (Anti-Pattern) ❌	Com Adapter (Design Pattern) ✅
Clareza	Lógica de conversão "suja" o código do cliente.	A conversão fica escondida na classe Adapter.
Acoplamento	O Cliente conhece detalhes da classe Legada.	O Cliente conhece apenas a Interface Alvo.
Manutenção	Alterar o legado quebra o cliente.	Alterar o legado requer ajuste apenas no Adapter.
Extensibilidade	Adicionar novo banco exige mudar o if/else do cliente.	Basta criar um novo Adapter, sem tocar no cliente.

---

📚 Conceitos Aplicados

• Adapter Pattern: Estrutural.
• Polimorfismo: O processador trata qualquer adaptador como um PaymentTarget.
• Open/Closed Principle (SOLID): O código está aberto para extensão (novos adapters) mas fechado para modificação (o processador não muda).

---

📄 Licença

Este projeto é de domínio público (Unlicense). Sinta-se livre para usar, modificar e distribuir sem restrições. Consulte o arquivo LICENSE para mais detalhes.

---

✉️ Contato

Desenvolvido por Mateus Nunes