Factory: a essência dos padrões Factory Method e Abstract Factory

O que é Factory: a essência do padrão de criação de objetos?

Factory — um padrão de design criacional do catálogo GoF. A ideia principal: mover a lógica de criação de objetos do código cliente para um método ou classe separada. O cliente trabalha com uma interface ou classe abstrata, enquanto a implementação concreta é criada pela fábrica. Isso implementa o princípio de Inversão de Dependência: o cliente não depende de classes concretas, apenas de abstrações.

Duas variedades de Factory: Factory Method e Abstract Factory. Factory Method — um único método numa classe que as subclasses sobrescrevem para criar objetos. Abstract Factory — uma interface com uma família de métodos de fábrica para criar grupos de objetos relacionados. Ambas as variantes resolvem o mesmo problema: o cliente não chama new MyClass() diretamente, mas pede à fábrica para criar um objeto conforme seu tipo ou parâmetros.

Factory vs new() — a criação direta de objetos acopla fortemente o código a uma implementação concreta. Factory adiciona uma camada: alterar a implementação requer editar apenas a fábrica, não todos os clientes. No desenvolvimento mobile, Factory é usado ativamente para criar ViewModel (ViewModelProvider.Factory), clientes de rede (Retrofit.create()), adaptadores de lista e fábricas de serialização. Contêineres DI (Dagger, Koin) geram fábricas automaticamente.

Factory Method: exemplos em Swift e Kotlin

Factory Method — um método declarado num protocolo ou classe abstrata que retorna um objeto de um tipo específico. As subclasses implementam o método, criando instâncias concretas. Em Swift, pode ser um método estático num protocolo ou um método numa classe base. Em Kotlin — um companion object com um método de fábrica ou open fun numa classe abstrata. O padrão é amplamente usado para criar parsers, fábricas de erro e construtores de consultas.

protocol PaymentGateway {
    func processPayment(amount: Decimal) async throws -> PaymentResult
}

final class StripeGateway: PaymentGateway { /* ... */ }
final class ApplePayGateway: PaymentGateway { /* ... */ }

enum PaymentType { case stripe, applePay }

final class PaymentFactory {
    // Factory Method
    static func create(type: PaymentType) -> PaymentGateway {
        switch type {
        case .stripe: return StripeGateway()
        case .applePay: return ApplePayGateway()
        }
    }
}

// Uso
let gateway = PaymentFactory.create(type: .stripe)

Versão Kotlin do Factory Method usa companion object ou sealed class para limitar tipos. Sealed class garante que o ramo when cubra todos os tipos possíveis — o compilador verifica a completude. Isso é típico em projetos Android onde a fábrica cria diferentes implementações de Repository ou DataSource conforme o build flavour ou configuração.

sealed class PaymentType {
    object Stripe : PaymentType()
    object ApplePay : PaymentType()
}

interface PaymentGateway {
    suspend fun processPayment(amount: BigDecimal): PaymentResult
}

class PaymentFactory {
    companion object {
        fun create(type: PaymentType): PaymentGateway = when (type) {
            PaymentType.Stripe -> StripeGateway()
            PaymentType.ApplePay -> ApplePayGateway()
        }
    }
}

Abstract Factory: famílias de objetos relacionados

Abstract Factory — um padrão para criar famílias de objetos relacionados ou interdependentes sem especificar suas classes concretas. O cliente trabalha com a interface da fábrica abstrata, que define métodos para criar cada produto da família. Uma fábrica concreta implementa a interface e cria objetos de uma variante específica. Por exemplo, uma fábrica de componentes UI para iOS cria UIButton, UILabel, UITableView, enquanto para Android — Button, TextView, RecyclerView.

Abstract Factory vs Factory Method — Factory Method cria um tipo de objeto através de herança, Abstract Factory cria uma família de objetos através de composição. Factory Method é sobrescrito em subclasses, Abstract Factory fornece múltiplos métodos de fábrica através de um protocolo. Abstract Factory frequentemente contém vários Factory Method. No desenvolvimento mobile, Abstract Factory é usado para componentes dependentes de plataforma, temas de design e fábricas de banco de dados.

Caso real de Abstract Factory no Android — implementação de diferentes tipos de banco de dados (SQLite vs Room) através de uma única interface DatabaseFactory. A fábrica cria objetos DAO, migrações e pools de conexão. No iOS — uma fábrica de serviços para diferentes ambientes (Development/Staging/Production). Abstract Factory raramente é usado diretamente — suas funções são assumidas por contêineres DI (Dagger Module, Swinject Assembly).

Factory no iOS: protocolos e métodos estáticos

Swift Factory é implementado através de protocolos e métodos estáticos. O protocolo Factory declara um método create() que retorna um tipo abstrato. Uma fábrica concreta implementa o protocolo e cria os objetos necessários. Swift não requer uma classe de fábrica separada para casos simples — um método estático num enum ou struct é suficiente. Para cenários complexos, um protocolo Factory com injeção DI é usado.

Factory no iOS SDK — muitas fábricas do sistema: UIStoryboard.instantiateViewController(withIdentifier:), NSKeyedUnarchiver.unarchivedObject(ofClass:from:), JSONDecoder().decode(_:from:). Desenvolvedores criam fábricas para ViewController (StoryboardFactory), para serviços (ServiceFactory) e para modelos de dados. Factory Method é usado ativamente nas arquiteturas VIPER e Clean Swift para criar módulos de tela.

Factory + DI — uma alternativa moderna: um contêiner DI (Swinject, Factory) gera automaticamente fábricas para tipos registrados. O contêiner armazena receitas de criação de objetos e resolve dependências. A biblioteca Factory (github.com/hmlongco/Factory) usa @Injected(.service) para injeção automática. Fábricas DI são testadas substituindo um módulo inteiro com uma única linha: container.register { MockService() }.

Factory no Android: companion factory e módulos DI

Android Factory — um exemplo clássico: ViewModelProvider.Factory para criar ViewModel com parâmetros. Google recomenda usar Hilt para geração automática de fábricas ViewModel — a anotação @HiltViewModel cria Factory automaticamente. Para objetos simples, um companion object com método create() ou invoke() é usado. Em Kotlin, o operador invoke permite chamar a fábrica como uma função: Factory(param).

Factory no Jetpack Compose — fábricas são usadas para criar estados e efeitos. remember { Factory.create() } cria um objeto no primeiro render e o preserva durante o ciclo de vida do composable. ViewModel no Compose é criado via viewModel() — esta é uma fábrica gerenciada pelo Hilt. No Compose, fábricas são menos comuns explicitamente, pois DI e Compose StateManager gerenciam a criação de objetos.

Factory vs Hilt — Dagger/Hilt gera automaticamente fábricas em tempo de compilação. @Module + @Providers substitui Factory Method, @Binds substitui Abstract Factory. Fábricas manuais permanecem relevantes para seleção dinâmica de implementação em tempo de execução (testes A/B, feature flags). Para dependências estáticas, Hilt automatiza completamente a criação de objetos — o desenvolvedor escreve apenas interfaces e anotações.