Builder — Grundlagen des Builder-Musters in der mobilen Entwicklung

Was ist Builder: das Wesen des Builder-Musters?

Builder — ein GoF-Erzeugungsmuster, das die Konstruktion eines komplexen Objekts von seiner Darstellung trennt. Derselbe Konstruktionsprozess kann verschiedene Darstellungen erzeugen. Builder ist nützlich, wenn ein Objekt viele optionale Parameter hat und ein Konstruktor mit zehn Feldern unlesbar und unflexibel ist. Das Muster löst auch das Telescoping-Constructor-Antimuster, bei dem die Anzahl der Konstruktorüberladungen exponentiell wächst.

Builder-Struktur umfasst eine innere statische Builder-Klasse mit Feldern, die die Felder der Hauptklasse widerspiegeln. Jede set-Methode gibt Builder (this) für fließende Verkettung zurück. Die finale build()-Methode erstellt das Zielobjekt, indem sie Feldwerte an einen privaten Konstruktor übergibt. Die Hauptklasse hat einen privaten Konstruktor, der einen Builder akzeptiert. Client: Object.builder().setField1(val1).setField2(val2).build().

Wann Builder verwenden — Objekte mit 5+ Feldern, von denen nur 2-3 erforderlich sind. Konfigurationsobjekte (RequestConfig, DatabaseConfig). Objekte mit komplexer Validierungslogik bei der Erstellung. Objekte, die nach der Erstellung unveränderlich (immutable) sein müssen. In Android wird Builder aktiv im SDK verwendet: AlertDialog.Builder, Retrofit.Builder, OkHttpClient.Builder, NotificationCompat.Builder.

Builder in Kotlin: klassische und DSL-Implementierung

Builder in Kotlin hat zwei Ansätze: klassischen Java-Stil Builder (über eine verschachtelte Klasse) und Kotlin-Stil DSL builder (über ein Lambda mit Empfänger). Der Java-Stil Builder ist für Android-Kompatibilität und bei Verwendung mit Java-Code vorzuziehen. Der DSL builder ist die idiomatische Kotlin-Methode: eine Funktion akzeptiert ein Lambda, innerhalb dessen this der Builder-Kontext ist, in dem Felder direkt zugewiesen werden können.

// Klassischer Builder
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)
        }
    }
}

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

Kotlin DSL builder — eine Alternative ohne verschachtelte Klasse. Eine Builder-Funktion akzeptiert ein Lambda im Kontext eines Builder-Objekts. Dies ist idiomatisch für Kotlin und erfordert keine write-Felder. DSL builders werden aktiv in Ktor Client, kotlinx.serialization, Compose (Modifier) verwendet. DSL builder ist mit Java inkompatibel und nicht für Bibliotheken mit Java-API geeignet.

Builder in Swift: result builders und Ketten

Builder in Swift — Swift hat kein eingebautes Builder-Muster, aber eine fließende Schnittstelle lässt sich leicht durch Methoden implementieren, die Self zurückgeben. Jede Methode konfiguriert eine Eigenschaft und gibt self zurück. Anders als Kotlin erfordert Swift keine separate Builder-Klasse — Sie können das Objekt selbst zurückgeben, wenn es während der Assemblierung veränderbar ist. Für unveränderliche Objekte wird eine verschachtelte Builder-Klasse ähnlich wie bei Kotlin verwendet.

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 führte @resultBuilder ein — ein Sprachmechanismus für deklarativen Strukturaufbau. SwiftUI, AttributedString, SceneBuilder verwenden result builders. Dies ist eine Alternative zum klassischen Builder: statt einer Kette von set-Methoden verwendet result builder einen Codeblock mit Elementen, die der Compiler zu einem Array oder Baum zusammenstellt. @ViewBuilder in SwiftUI ist das bekannteste Beispiel: innerhalb von body können if, switch, ForEach geschrieben werden, und der Compiler baut aus den Bedingungen eine View.

Builder vs Telescoping Constructor: Ansatzvergleich

Telescoping Constructor — ein Antimuster, bei dem eine Klasse viele überladene Konstruktoren mit verschiedenen Parametersätzen hat. Zum Beispiel drei Konstruktoren: HttpConfig(url), HttpConfig(url, timeout), HttpConfig(url, timeout, retries). Mit wachsenden Parametern steigt die Anzahl der Konstruktoren exponentiell — für n optionale Felder werden n! Kombinationen benötigt. Builder löst dieses Problem, indem er nur die benötigten Felder angeben lässt.

Kotlin named arguments + Standardwerte — eine elegante Alternative zu Builder in reinen Kotlin-Projekten. Konstruktorparameter haben Standardwerte, der Client übergibt nur die benötigten: HttpConfig(baseUrl = url, timeout = 15_000). Der Nachteil ist die Unfähigkeit, erforderliche Felder zur Kompilierzeit zu validieren. Builder bietet erforderliche Felder durch den Builder-Konstruktor (baseUrl ist erforderlich). Für Java-Bibliotheken bleibt Builder der De-facto-Standard.

Builder im Android SDK: AlertDialog, Retrofit, OkHttp

Builder im Android SDK — eines der häufigsten Muster in der Standardbibliothek. 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().

Warum Google Builder verwendet — Rückwärtskompatibilität. Das Hinzufügen einer neuen Methode zu Builder bricht bestehenden Code nicht. Wenn Google einen Konstruktor mit 20 Parametern verwendet hätte, würde jedes neue Feld eine neue Überladung erfordern. Builder erlaubt das Hinzufügen von set-Methoden über Jahre ohne breaking changes. Beispielsweise fügte NotificationCompat.Builder in Android 11 setBubbleMetadata() hinzu, ohne bestehenden Code zu beeinträchtigen.

Builder in Kotlin-Bibliotheken — Ktor (HttpClientBuilder), Coil (ImageRequest.Builder), Room (Room.databaseBuilder(context, AppDatabase.class, "db").fallbackToDestructiveMigration().build()), Navigation (NavOptionsBuilder). In Kotlin-Projekten wird Builder oft mit DSL kombiniert: Room.databaseBuilder(context, AppDatabase.class, "db").fallbackToDestructiveMigration().build(). Das Muster bleibt für öffentliche APIs relevant, bei denen Rückwärtskompatibilität und Java-Interop wichtig sind.