Builder — fundamentos do padrão builder no desenvolvimento móvel

O que é Builder: a essência do padrão construtor?

Builder — um padrão criacional GoF que separa a construção de um objeto complexo de sua representação. O mesmo processo de construção pode criar diferentes representações. Builder é útil quando um objeto tem muitos parâmetros opcionais e um construtor com dez campos é ilegível e inflexível. O padrão também resolve o antipadrão Telescoping Constructor, onde o número de sobrecargas do construtor cresce exponencialmente.

Estrutura do Builder inclui uma classe interna estática Builder com campos espelhando os campos da classe principal. Cada set-método retorna Builder (this) para encadeamento fluido. O método final build() cria o objeto alvo passando os valores dos campos para um construtor privado. A classe principal tem um construtor privado que aceita um Builder. Cliente: Object.builder().setField1(val1).setField2(val2).build().

Quando usar Builder — objetos com 5+ campos onde apenas 2-3 são obrigatórios. Objetos de configuração (RequestConfig, DatabaseConfig). Objetos com lógica complexa de validação durante a criação. Objetos que devem ser imutáveis após a criação. No Android, Builder é ativamente usado no SDK: AlertDialog.Builder, Retrofit.Builder, OkHttpClient.Builder, NotificationCompat.Builder.

Builder em Kotlin: implementação clássica e DSL

Builder em Kotlin tem duas abordagens: Builder clássico estilo Java (através de uma classe aninhada) e Builder DSL estilo Kotlin (através de uma lambda com receptor). O Builder estilo Java é preferível para compatibilidade com Android e quando usado com código Java. O DSL builder é a forma idiomática do Kotlin: uma função aceita uma lambda dentro da qual this é o contexto Builder onde campos podem ser atribuídos diretamente.

// Builder clássico
data class HttpConfig private constructor(
    val baseUrl: String,
    val timeout: Long = 30_000,
    val retries: Int = 3,
    val headers: Map<String, String> = emptyMap()
) {
    class Builder {
        private var baseUrl: String = ""
        private var timeout: Long = 30_000
        private var retries: Int = 3
        private var headers: MutableMap<String, String> = mutableMapOf()

        fun baseUrl(url: String) = apply { this.baseUrl = url }
        fun timeout(ms: Long) = apply { this.timeout = ms }
        fun retries(n: Int) = apply { this.retries = n }
        fun header(key: String, value: String) = apply { headers[key] = value }

        fun build(): HttpConfig {
            require(baseUrl.isNotBlank()) { "baseUrl is required" }
            return HttpConfig(baseUrl, timeout, retries, headers)
        }
    }
}

// Uso
val config = HttpConfig.Builder()
    .baseUrl("https://api.example.com")
    .timeout(15_000)
    .header("Authorization", "Bearer token")
    .build()

Kotlin DSL builder — uma alternativa sem classe aninhada. Uma função builder aceita uma lambda no contexto de um objeto construtor. Isto é idiomático para Kotlin e não requer write-fields. DSL builders são ativamente usados no Ktor Client, kotlinx.serialization, Compose (Modifier). O DSL builder é incompatível com Java e não é adequado para bibliotecas com API Java.

Builder em Swift: result builders e cadeias

Builder em Swift — Swift não tem um padrão Builder embutido, mas a interface fluida é facilmente implementada através de métodos que retornam Self. Cada método configura uma propriedade e retorna self. Diferente do Kotlin, Swift não requer uma classe Builder separada — você pode retornar o próprio objeto se ele for mutável durante a montagem. Para objetos imutáveis, uma classe Builder aninhada é usada de forma similar ao Kotlin.

struct NetworkRequest {
    let url: String
    let method: HTTPMethod
    let headers: [String: String]
    let body: Data?
    let timeout: TimeInterval

    final class Builder {
        private var url: String = ""
        private var method: HTTPMethod = .get
        private var headers: [String: String] = [:]
        private var body: Data? = nil
        private var timeout: TimeInterval = 30

        func withURL(_: String) -> Self { /* self */ }
        func withMethod(_: HTTPMethod) -> Self { /* self */ }
        func withHeader(key: String, value: String) -> Self { /* self */ }
        func withBody(_: Data) -> Self { /* self */ }
        func withTimeout(_: TimeInterval) -> Self { /* self */ }

        func build() throws -> NetworkRequest {
            guard !url.isEmpty else { throw BuilderError.missingURL }
            return NetworkRequest(
                url: url, method: method, headers: headers,
                body: body, timeout: timeout
            )
        }
    }
}

Result Builders — Swift 5.4 introduziu @resultBuilder — um mecanismo de linguagem para construção declarativa de estruturas. SwiftUI, AttributedString, SceneBuilder usam result builders. É uma alternativa ao Builder clássico: em vez de uma cadeia de set-métodos, result builder usa um bloco de código com elementos que o compilador monta em um array ou árvore. @ViewBuilder no SwiftUI é o exemplo mais famoso: dentro de body você pode escrever if, switch, ForEach, e o compilador constrói uma View a partir das condições.

Builder vs Telescoping Constructor: comparação de abordagens

Telescoping Constructor — um antipadrão onde uma classe tem múltiplos construtores sobrecarregados com diferentes conjuntos de parâmetros. Por exemplo, três construtores: HttpConfig(url), HttpConfig(url, timeout), HttpConfig(url, timeout, retries). À medida que os parâmetros crescem, o número de construtores cresce exponencialmente — para n campos opcionais são necessárias n! combinações. Builder resolve este problema permitindo especificar apenas os campos necessários.

Kotlin named arguments + valores padrão — uma alternativa elegante ao Builder em projetos puramente Kotlin. Os parâmetros do construtor têm valores padrão, o cliente passa apenas os necessários: HttpConfig(baseUrl = url, timeout = 15_000). A desvantagem é a incapacidade de validar campos obrigatórios em tempo de compilação. Builder fornece campos obrigatórios através do construtor Builder (baseUrl é obrigatório). Para bibliotecas Java, Builder continua sendo o padrão de fato.

Builder no Android SDK: AlertDialog, Retrofit, OkHttp

Builder no Android SDK — um dos padrões mais comuns na biblioteca padrão. AlertDialog.Builder: new AlertDialog.Builder(context).setTitle().setMessage().setPositiveButton().create(). Retrofit.Builder: new Retrofit.Builder().baseUrl().addConverterFactory().build(). OkHttpClient.Builder: new OkHttpClient.Builder().connectTimeout().addInterceptor().build(). NotificationCompat.Builder: setContentTitle().setContentText().setSmallIcon().build().

Por que o Google usa Builder — compatibilidade retroativa. Adicionar um novo método ao Builder não quebra o código existente. Se o Google usasse um construtor com 20 parâmetros, cada novo campo exigiria uma nova sobrecarga. Builder permite adicionar set-métodos por anos sem breaking changes. Por exemplo, NotificationCompat.Builder adicionou setBubbleMetadata() no Android 11 sem afetar o código existente.

Builder em bibliotecas Kotlin — Ktor (HttpClientBuilder), Coil (ImageRequest.Builder), Room (Room.databaseBuilder(context, AppDatabase.class, "db").fallbackToDestructiveMigration().build()), Navigation (NavOptionsBuilder). Em projetos Kotlin, Builder é frequentemente combinado com DSL: Room.databaseBuilder(context, AppDatabase.class, "db").fallbackToDestructiveMigration().build(). O padrão permanece relevante para APIs públicas onde a compatibilidade retroativa e a interoperabilidade Java são importantes.