Executando verificação de segurança...
2
rphlfc
11 min de leitura ·

Pedi para a IA responder 4 perguntas sobre 4 padrões de projeto que usei na biblioteca do TabNews para Kotlin

Pedi para a IA falar a respeito de 4 padrões de projeto que utilizo na biblioteca da API do TabNews para Kotlin. Os padrões foram:

  • Repository
  • Builder
  • Singleton
  • DAO

As perguntas foram as seguintes:

  • Qual a teoria do padrão
  • Qual a classificação do padrão
  • Que tipo de problema ele resolve
  • E por que esse é o melhor padrão para resolver o problema no meu projeto

Ao final ainda adicionei uma pergunta sobre por que não usar o Repository para todo acesso a dados e usar o DAO para tudo e vice versa, usar o DAO pra tudo e não usar o Repository.

Analisei a resposta, fiz algumas alterações e estou compartilhando o resultado aqui com vocês.

Análise: Padrões de projeto

1. Padrão Repository

Teoria

O Padrão Repository é um padrão de design que cria uma camada de abstração entre a lógica de negócio e as camadas de acesso a dados. Ele funciona como um mediador entre objetos de domínio e camadas de mapeamento de dados, usando uma interface similar a uma coleção para acessar objetos de domínio.

Conceito:

  • O repositório encapsula a lógica necessária para acessar fontes de dados
  • Fornece uma interface uniforme para operações de acesso a dados
  • Abstrai a complexidade dos mecanismos de persistência de dados
  • A lógica de negócio interage com repositórios, não diretamente com fontes de dados

Princípios:

  1. Abstração: Esconde os detalhes de acesso a dados da lógica de negócio
  2. Separação de responsabilidades: A lógica de negócio não precisa saber sobre SQL, chamadas de API ou cache
  3. Testabilidade: Fácil de criar mocks dos repositórios para testes unitários
  4. Flexibilidade: Pode trocar fontes de dados sem alterar a lógica de negócio

Tipo

Padrão comportamental (embora alguns o classifiquem como Padrão arquitetural)

O padrão Repository define como objetos se comunicam e interagem, especificamente como a lógica de negócio acessa dados sem conhecer os detalhes da implementação.

Problemas que resolve

  1. Acoplamento forte: Sem repositórios, a lógica de negócio fica diretamente acoplada a mecanismos de acesso a dados (REST APIs, bancos de dados, etc.)
  2. Duplicação de código: Lógica de acesso a dados espalhada por múltiplas classes
  3. Dificuldade de teste: Difícil testar lógica de negócio quando está fortemente acoplada a fontes de dados reais
  4. Múltiplas fontes de dados: Cenários complexos onde dados vêm de APIs, cache local, bancos de dados simultaneamente
  5. Gestão de mudanças: Alterar fontes de dados requer modificar a lógica de negócio

Por que foi a melhor abordagem para este projeto

Olhando para ContentRepositoryImpl:

internal class ContentRepositoryImpl(
    private val api: APIService,
    private val cacheManager: CacheManager
) : ContentRepository

Explicação:

  1. Múltiplas fontes de dados: O projeto precisa buscar dados de:

    • REST API (APIService)
    • Cache local (CacheManager)
    • O repositório orquestra ambos de forma transparente

  2. Lógica de cache: O método getContents() demonstra um cache:

    // Verifica cache primeiro
if (!clearCache) {
    val cachedContents = cacheManager.getContents(strategy.param, page)
    if (cachedContents != null && cachedContents.isNotEmpty()) {
        return APIResult.Success(contents)
    }
}
// Fallback para cache em caso de falha da API
return result.getOrFallbackToCache {
    getCachedContents(strategy.param, page)
}

    Essa complexidade fica escondida dos consumidores - eles só chamam getContents().

  3. Testabilidade: Fácil testar ContentRepository criando mocks de APIService e CacheManager:

    val mockApi = mock<APIService>()
val mockCache = mock<CacheManager>()
val repository = ContentRepositoryImpl(mockApi, mockCache)

  4. Interface: Todos os repositórios (ContentRepository, AuthRepository, UserRepository) seguem o mesmo padrão, tornando o código previsível.

  5. Preparado para o futuro: Se precisar adicionar suporte offline-first, persistência em banco de dados, ou trocar provedores de API, você só modifica a implementação do repositório, não os consumidores.

2. Padrão Builder

Teoria

O Padrão Builder separa a construção de um objeto complexo da sua representação, permitindo que o mesmo processo de construção crie diferentes representações.

Conceito:

  • Usa uma abordagem passo a passo para construir objetos
  • Fornece uma interface fluente (encadeamento de métodos)
  • Permite parâmetros opcionais sem sobrecarga de construtores
  • Encapsula lógica de inicialização complexa

Componentes:

  1. Classe Builder: Contém métodos para definir vários parâmetros
  2. Método build: Constrói e retorna o objeto final
  3. Interface: Métodos retornam o próprio builder para encadeamento

Tipo

Padrão criacional

O padrão Builder está preocupado com a criação de objetos, especificamente criando objetos complexos passo a passo.

Problemas que resolve

  1. Anti-padrão de construtor Ttelescópico: Evita construtores com muitos parâmetros

    // Ruim: Construtor telescópico
APIClient(context, url, timeout1, timeout2, timeout3, enableLogging, json, dispatcher)

// Bom: Padrão builder
APIClient.Builder(context)
    .baseUrl(url)
    .timeouts(30, 30, 30)
    .enableLogging(true)
    .build()

  2. Parâmetros opcionais: Muitas opções de configuração, mas nem todas são obrigatórias

  3. Legibilidade: Torna o código auto-documentado através de nomes de métodos

  4. Imutabilidade: Pode criar objetos imutáveis com todos os campos definidos

  5. Validação: Pode validar parâmetros antes da construção do objeto

Por que foi a melhor abordagem para este projeto

Olhando para APIClient.Builder:

class APIClient private constructor(
    private val context: Context,
    private val apiService: APIService,
    private val config: APIClientConfig,
    private val tokenProvider: TokenProvider
) {
    class Builder(ctx: Context) {
        private var config: APIClientConfig = APIClientConfig()
        
        fun baseUrl(url: String) = apply { config = config.copy(baseUrl = url) }
        fun timeouts(connectSeconds: Long, readSeconds: Long, writeSeconds: Long) = apply {
            config = config.copy(...)
        }
        fun enableLogging(enable: Boolean) = apply { config = config.copy(enableLogging = enable) }
        fun json(json: Json) = apply { config = config.copy(json = json) }
        fun dispatcher(dispatcher: CoroutineDispatcher) = apply { ... }
        
        fun build(): APIClient {
            // Lógica de inicialização complexa
            val tokenProvider = TokenProviderImpl(context)
            val okBuilder = getOkBuilder(context, tokenProvider)
            val retrofit = Retrofit.Builder()...
            return APIClient(context, apiService, config, tokenProvider)
        }
    }
}

Explicação:

  1. Muitas opções de configuração: O cliente de API tem várias configurações:

    • URL base
    • Três timeouts diferentes (conexão, leitura, escrita)
    • Toggle de logging
    • Configuração JSON
    • Dispatcher de corrotinas
    • Todas opcionais com valores padrão sensatos

  2. Inicialização complexa: O método build() orquestra uma configuração complexa:

    fun build(): APIClient {
    val tokenProvider = TokenProviderImpl(context)
    val okBuilder = getOkBuilder(context, tokenProvider)
    val okHttpClient = okBuilder.build()
    val retrofit = Retrofit.Builder()...
    val apiService = retrofit.create(APIService::class.java)
    return APIClient(context, apiService, config, tokenProvider).apply {
        initializeCacheCleanup()
    }
}

    Essa complexidade fica escondida dos usuários.

  3. API fluente: Torna a configuração legível e descobrível:

    val apiClient = APIClient.Builder(this)
    .baseUrl("https://api.example.com")
    .timeouts(30, 30, 30)
    .enableLogging(true)
    .build()

  4. Configuração padrão: APIClientConfig() fornece valores padrão sensatos, então os usuários só especificam o que precisam.

  5. Imutabilidade: Uma vez construído, APIClient é imutável (construtor privado), prevenindo modificação acidental.

  6. Oportunidade de validação: O builder pode validar configuração antes da construção (por exemplo, verificar formato de URL, intervalos de timeout).

3. Padrão Singleton

Teoria

O Padrão Singleton garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global a ela.

Conceito:

  • Restringe a instanciação a um único objeto
  • Fornece acesso controlado a essa instância
  • Frequentemente usa inicialização preguiçosa (lazy)
  • Acesso thread-safe em ambientes multi-threaded

Características:

  1. Construtor privado: Previne instanciação externa
  2. Variável de instância estática: Mantém a única instância
  3. Método de acesso público: Fornece acesso controlado à instância
  4. Thread safety: Garante apenas uma instância em cenários concorrentes

Tipo

Padrão criacional

O padrão Singleton controla a criação de objetos, garantindo que apenas uma instância exista.

Problemas que resolve

  1. Gestão de recursos: Previne múltiplas instâncias de recursos caros (conexões de banco de dados, handles de arquivo)
  2. Consistência de estado: Garante que estado compartilhado permaneça consistente em toda a aplicação
  3. Acesso global: Fornece um ponto de acesso bem conhecido a um recurso
  4. Eficiência de memória: Evita criar múltiplas instâncias do mesmo recurso

Por que foi a melhor abordagem para este projeto

Olhando para CacheDatabase:

abstract class CacheDatabase : RoomDatabase() {
    companion object {
        @Volatile
        private var INSTANCE: CacheDatabase? = null
        
        fun getDatabase(context: Context): CacheDatabase {
            return INSTANCE ?: synchronized(this) {
                val instance = Room.databaseBuilder(
                    context.applicationContext,
                    CacheDatabase::class.java,
                    "content_cache_database"
                )
                    .fallbackToDestructiveMigration()
                .build()
                INSTANCE = instance
                instance
            }
        }
    }
}

Explicação:

  1. Gestão de conexão de banco de dados: Bancos de dados Room são caros para criar:

    • Operações de I/O de arquivo
    • Validação de schema
    • Configuração de pool de conexões
    • Criar múltiplas instâncias desperdiçaria recursos e poderia causar conflitos

  2. Thread safety: A implementação usa:

    • @Volatile: Garante visibilidade entre threads
    • synchronized: Previne condições de corrida durante inicialização
    • Padrão double-checked locking: Singleton thread-safe eficiente

  3. Acesso: Múltiplos repositórios (ContentRepositoryImpl, gerenciadores de cache) precisam da mesma instância do banco de dados:

    // Em APIClient
private val cacheDatabase: CacheDatabase by lazy {
    CacheDatabase.getDatabase(context)
}

    Todos os componentes compartilham a mesma instância do banco de dados.

  4. Requisitos de context do Android: Room requer um ApplicationContext (não contexto de Activity), e o singleton garante gestão adequada do ciclo de vida.

  5. Previne problemas de lock de banco de dados: Múltiplas instâncias de banco de dados poderiam causar conflitos de lock do SQLite. Singleton previne isso.

  6. Eficiência de memória: Instâncias de banco de dados mantêm conexões e caches. Uma instância = um conjunto de recursos.

Nota:
Embora Singleton tenha desvantagens (estado global, dificuldades de teste), para bancos de dados Room no Android, é a abordagem recomendada pelo Google. O padrão é apropriado aqui porque:

  • Conexões de banco de dados são recursos inerentemente compartilhados
  • O ciclo de vida da aplicação Android se alinha com o escopo singleton
  • O design do Room espera uso singleton

4. Padrão DAO (Data Access Object)

Teoria

O Padrão DAO fornece uma interface abstrata para um banco de dados ou mecanismo de persistência, encapsulando todas as operações de acesso a dados para uma entidade específica ou conjunto de entidades relacionadas.

Conceito:

  • Separa lógica de acesso a dados da lógica de negócio
  • Fornece uma interface limpa para operações CRUD
  • Abstrai detalhes específicos do banco de dados (SQL, queries)
  • Cada DAO tipicamente lida com um tipo de entidade

Princípios:

  1. Responsabilidade única: Cada DAO lida com acesso a dados de uma entidade
  2. Abstração: Esconde detalhes SQL/banco de dados da lógica de negócio
  3. Reutilização: DAOs podem ser reutilizados em diferentes partes da aplicação
  4. Testabilidade: Fácil criar mocks de DAOs para teste

Tipo

Padrão Estrutural (embora frequentemente considerado Padrão Arquitetural)

O Padrão DAO estrutura como o acesso a dados é organizado e abstraído do resto da aplicação.

Problemas que resolve

  1. Acoplamento: Sem DAOs, a lógica de negócio contém queries SQL e código específico do banco de dados
  2. Organização: Espalha código de acesso a dados por toda a aplicação
  3. Vendor lock-in: Torna difícil trocar bancos de dados
  4. Complexidade: Queries SQL misturadas com lógica de negócio reduzem legibilidade
  5. Teste: Difícil testar lógica de negócio quando contém código de banco de dados
  6. Manutenibilidade: Mudanças no schema do banco de dados requerem mudanças em todo o código

Por que foi a melhor abordagem para este projeto

Olhando para as implementações de DAO:

@Dao
interface ContentCacheDao {
    @Query("SELECT * FROM cached_content WHERE strategy = :strategy AND page = :page")
    suspend fun getContentsByStrategyAndPage(strategy: String, page: Int): List<CachedContent>
    
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertContents(contents: List<CachedContent>)
    
    @Query("DELETE FROM cached_content WHERE strategy = :strategy")
    suspend fun deleteContentsByStrategy(strategy: String)
}

Explicação:

  1. Separação: Cada DAO lida com um tipo de entidade:

    • ContentCacheDao: Itens de conteúdo em cache
    • MetadataCacheDao: Metadados de cache (expiração, chaves)
    • PostDetailCacheDao: Informações detalhadas de posts

    Essa separação torna o código organizado e manutenível.

  2. Integração com Room: Room (abstração SQLite do Android) usa DAOs como sua abstração primária:

    abstract class CacheDatabase : RoomDatabase() {
    abstract fun contentCacheDao(): ContentCacheDao
    abstract fun cacheMetadataDao(): MetadataCacheDao
    abstract fun postDetailCacheDao(): PostDetailCacheDao
}

    O padrão DAO é a forma idiomática de usar Room.

  3. Queries encapsuladas: DAOs escondem SQL complexo:

    @Query("SELECT * FROM cached_content WHERE strategy = :strategy AND page <= :maxPage ORDER BY page ASC, cached_at DESC")
suspend fun getContentsUpToPage(strategy: String, maxPage: Int): List<CachedContent>

    A lógica de negócio não precisa saber sobre ordenação SQL, lógica de paginação, etc.

  4. Type safety: Room gera código de implementação em tempo de compilação, fornecendo:

    • Validação de query em tempo de compilação
    • Tipos de retorno type-safe
    • Sem erros SQL em runtime

  5. Funções suspend: DAOs usam corrotinas Kotlin (suspend), tornando-os:

    • Não-bloqueantes
    • Fáceis de usar em código baseado em corrotinas
    • Integram perfeitamente com CacheManager

  6. Testabilidade: Fácil criar mocks de DAOs:

    val mockDao = mock<ContentCacheDao>()
val cacheManager = CacheManager(mockDatabase)

  7. Resolução de conflitos: DAOs lidam com preocupações específicas do banco de dados:

    @Insert(onConflict = OnConflictStrategy.REPLACE)
suspend fun insertContents(contents: List<CachedContent>)

    A lógica de negócio não precisa saber sobre resolução de conflitos do SQLite.

  8. Otimização de queries: DAOs permitem que Room otimize queries:

    • Compilação de queries
    • Pool de conexões
    • Prepared statements
    • Tudo tratado de forma transparente

Exemplo:

// Em CacheManager - interface limpa e simples
suspend fun getContents(strategy: String, page: Int): List<CachedContent>? {
    return withContext(Dispatchers.IO) {
        val metadata = metadataDao.getMetadataByKey(cacheKey)
        if (metadata != null && metadata.expires_at > System.currentTimeMillis()) {
            contentCacheDao.getContentsByStrategyAndPage(strategy, page)
        } else null
    }
}

O padrão DAO torna esse código legível e de fácil manutenção - sem strings SQL, sem gestão de conexão de banco de dados, apenas chamadas de método limpas.

5. Por que Repository para API e DAO para banco de dados?

Essa é uma pergunta que surge naturalmente quando analisamos a arquitetura: por que usar o padrão Repository para acessar dados da API, mas usar o padrão DAO para acessar dados do banco de dados? Por que não usar Repository para tudo, ou DAO para tudo?

A diferença fundamental

A resposta está na natureza diferente dessas duas fontes de dados e nos problemas específicos que cada padrão resolve melhor.

Por que não usar DAO para API?

Problemas que surgiriam:

  1. DAO é específico para bancos de dados: O padrão DAO foi criado especificamente para abstrair operações de banco de dados (CRUD). Ele funciona perfeitamente com Room porque:

    • Room gera código SQL em tempo de compilação
    • Queries são estáticas e conhecidas antecipadamente
    • Operações são tipicamente síncronas ou suspend (bloqueantes de forma controlada)

  2. APIs REST são diferentes: Chamadas de API têm características completamente diferentes:

    • Requisições HTTP assíncronas
    • Tratamento de erros de rede
    • Autenticação e interceptores
    • Cache HTTP
    • Retry logic
    • Transformação de dados (JSON parsing)

    Tentar usar DAO para API seria como usar uma chave de fenda para martelar um prego - ferramenta errada para o trabalho.

  3. Orquestração complexa: No nosso projeto, ContentRepositoryImpl precisa:

    // 1. Verificar cache primeiro
// 2. Se não tiver, chamar API
// 3. Se API falhar, tentar cache novamente
// 4. Transformar dados entre formatos

    Um DAO não tem essa capacidade de orquestração - ele só faz operações simples de banco de dados.

Por que não usar Repository para banco de dados?

Problemas que surgiriam:

  1. Perderíamos os benefícios do Room: Room é uma biblioteca poderosa que:

    • Valida queries em tempo de compilação
    • Gera código type-safe automaticamente
    • Otimiza queries automaticamente
    • Gerencia conexões e transações

    Se criássemos um Repository que encapsula DAOs, estaríamos apenas adicionando uma camada desnecessária. O Repository já usa DAOs internamente através do CacheManager.

  2. Granularidade inadequada: Repositories trabalham em nível de domínio (ex: "buscar conteúdos"), enquanto DAOs trabalham em nível de persistência (ex: "SELECT * FROM cached_content WHERE...").

    Olhando nosso código:

    // Repository: nível de domínio
suspend fun getContents(page: Int, strategy: Strategy): APIResult<List<Content>>

// DAO: nível de persistência
suspend fun getContentsByStrategyAndPage(strategy: String, page: Int): List<CachedContent>

  3. Separação de responsabilidades: DAOs têm uma responsabilidade muito específica e bem definida: operações de banco de dados. Repositories têm uma responsabilidade mais ampla: orquestrar múltiplas fontes de dados e aplicar lógica de negócio.

Carregando publicação patrocinada...