# Entendendo o Padrão Repository

O Get Smart SDK (`redsys-tpv-business-lib`) é projetado em torno do **Padrão Repository**, um padrão essencial no desenvolvimento Android moderno que se integra naturalmente em projetos MVVM e Clean Architecture.

Em vez de expor chamadas de serviço de baixo nível diretamente para suas Activities ou Fragments, o SDK agrupa as operações em interfaces de repositório focadas (ex: `InitializationRepository`, `PaymentRepository`, `RefundRepository`, `TransactionRepository`).

## Arquitetura de Alto Nível

O repositório atua como uma camada de abstração segura entre sua aplicação e o Get Smart SDK Payment Service (o serviço de segundo plano executado no dispositivo).

Em alto nível, cada repositório:

- Encapsula toda a comunicação com o **Get Smart SDK Payment Service** instalado no dispositivo.
- Expõe **funções `suspend` do Kotlin** que sempre retornam um wrapper `RepositoryResult<T>`.
- Move automaticamente a execução para o `Dispatchers.IO`, mantendo sua thread principal livre de operações de E/S bloqueantes.
- Mantém sua camada de UI e UseCases independentes da implementação subjacente.

### Benefícios para sua arquitetura

O uso de repositórios desta forma oferece várias vantagens concretas:

- **Desacoplamento**: Seu app depende apenas das interfaces dos repositórios (contratos), não das classes de implementação concretas ou do protocolo do serviço.
- **Pronto para Injeção de Dependência**: Os repositórios são projetados para serem fornecidos como singletons via **Dagger Hilt** (ou manualmente via `RepositoryProvider`), mantendo a raiz de composição do seu projeto limpa.
- **Testabilidade**: Como o SDK é baseado em interfaces, você pode facilmente substituir os repositórios reais por fakes ou mocks em seus testes unitários, sem precisar de um TPV físico ou do Serviço de Pagamento.
- **Segurança de Threads (Thread safety)**: Como todas as operações são funções suspend que delegam para dispatchers de segundo plano seguros, você não precisa gerenciar threads ou callbacks manualmente.

### Fluxo de uso típico

Em uma estrutura MVVM típica:

1. Seu container de DI (por exemplo, um módulo Hilt) cria uma única instância de `RepositoryProvider` com o `Context` da aplicação.
2. O provedor expõe instâncias de repositórios concretos, como `initializationRepository`, `paymentRepository`, `transactionRepository`, entre outros.
3. Os ViewModels recebem esses repositórios via injeção de construtor e chamam suas funções suspend a partir de corrotinas.
4. Cada chamada retorna um `RepositoryResult<T>` que o ViewModel converte em estado de UI.

Para mais detalhes sobre como conectar os repositórios ao seu grafo de DI, consulte **`Primeiros Passos / Configurar Injeção de Dependência`**. Para entender a semântica do wrapper `RepositoryResult<T>` e como interpretar seus diferentes ramos, consulte **`Conceitos Principais / Tratar Respostas e Erros`** e **`Referência / Códigos de Resposta e Erro`**.