Cuando desarrollas una app con Swift, llega un momento en que el código de inicialización acaba teniendo este aspecto.
User(name:age:email:phone:address:isVerified:profileURL:createdAt:)
Ocho parámetros dentro de los paréntesis.
Al mirar el código de llamada, terminas contando uno a uno para saber qué valor es email y cuál es phone.
Es una situación habitual incluso en proyectos personales, pero el Builder Pattern de Swift la resuelve de forma limpia.
En resumen, la inicialización con muchos parámetros resulta mucho más legible si el Builder Pattern permite configurarlos «uno por línea». Ya no necesitas recordar el orden ni rellenar a la fuerza con nil los valores que no usas.
Este es un resumen de lo que aprenderás en este artículo.
- Por qué un init de 8 parámetros provoca errores
- Cómo lo resuelve el Builder Pattern
- Cómo se escribe realmente en Swift
- Cuándo usar este patrón y cuándo evitarlo
¿Por qué es un infierno un init de 8 parámetros?
Con tres o cuatro parámetros, en realidad no suele haber problemas.
El problema empieza cuando aumenta la cantidad.
Primero, puedes equivocarte de orden. Si pasas phone donde va email y ambos son String, el compilador no lo detectará.
Segundo, el tratamiento de los valores opcionales se vuelve engorroso. Tienes que rellenar incluso los valores que no usas ahora con nil, nil, nil.
Tercero, el sitio de llamada se alarga y deja de quedar claro qué objeto estás creando.
Cuantos más parámetros hay, más se convierte init en un examen lleno de casillas que rellenar; y cuantas más casillas, más errores.
Un bug por intercambiar las posiciones de phone y profileURL puede llevarte más de un día. Cuando los tipos coinciden, estos errores pasan realmente desapercibidos.
¿Qué es el Builder Pattern?
El Builder Pattern crea un objeto complejo rellenando los valores uno a uno y finalizándolo al final, en lugar de crearlo todo de una vez.
En vez de pasar todos los valores durante la inicialización, eliges y configuras solo los necesarios, y obtienes el objeto final mediante un método como build().
Piensa en pedir comida en un restaurante. En lugar de decir todos los ingredientes de golpe, dices: «Pan integral, queso extra y sin salsa», elemento por elemento.
Si el método que configura un valor clave devuelve el propio objeto, puedes encadenar llamadas con puntos. Este es el builder más sencillo.
final class UserBuilder {
private var name = ""
private var email: String?
// Configura un valor y selfdevuélvelo para permitir el encadenamiento
func setName(_ v: String) -> Self { name = v; return self }
func setEmail(_ v: String) -> Self { email = v; return self }
func build() -> User { User(name: name, email: email) }
}Como el método de configuración devuelve Self, puedes encadenarlo como .setName(...).setEmail(...).
¿Cómo se usa el Builder Pattern en Swift?
Probablemente lo que más te interesa es cómo cambia el sitio de llamada real.
Al usar el builder creado antes, el código de creación del objeto cambia así.
// Configura solo los valores necesarios, con etiquetas y sin preocuparte por el orden
let user = UserBuilder()
.setName("Seokwoo Lee")
.setEmail("[email protected]")
.build()
// Ya no hace falta rellenar los valores sin usar con nilComo ves, no tienes que preocuparte por el orden. El nombre del método funciona como etiqueta y evita estructuralmente errores como pasar phone donde va email.
Para los valores que no usas, simplemente no llamas al método.
En Swift también es habitual crear el builder con un struct en lugar de una class, o pasar un closure para configurarlo dentro de un solo bloque. Elige según el estilo del proyecto.
Cuándo usar el Builder Pattern y cuándo evitarlo
Añadirlo en todas partes solo porque parece útil hará que el código crezca sin necesidad.
He resumido mis criterios en una tabla (según mi experiencia en proyectos personales hasta 2026).
| Situación | Recomendación |
|---|---|
| 5 o más parámetros y muchos valores opcionales | Builder Pattern |
| Varios parámetros del mismo tipo | Builder Pattern |
| 2 o 3 parámetros, todos obligatorios | init normal |
| Valores simples y fijos | init normal |
En resumen, si hay pocos parámetros y todos son obligatorios, no tiene sentido crear un builder.
En cambio, para un objeto grande con valores opcionales mezclados, un builder resulta mucho más cómodo.
P. ¿Crear un builder no añade más código?
Es cierto. La propia clase builder añade código. Pero si creas ese objeto en varios lugares, el beneficio de limpiar los sitios de llamada es mayor.
P. Swift tiene parámetros predeterminados. ¿No puedo usar eso?
Con tres o cuatro parámetros, los parámetros predeterminados son suficientes. El Builder Pattern destaca cuando hay muchos parámetros y combinaciones variadas.
Si te estresa un init de 8 parámetros, prueba a aplicar el Builder Pattern justo ahí. No necesitas rehacerlo todo: empezar por el objeto más complejo reduce el esfuerzo. ¡Feliz programación!