El patrón Builder resuelve un problema clásico en programación orientada a objetos: cómo crear objetos complejos con múltiples representaciones sin terminar con docenas de clases o constructores gigantes. Si trabajas con productos que comparten un proceso de construcción pero varían en sus detalles, este patrón te interesa.

¿Qué es el patrón Builder y por qué importa?

Builder es un patrón de diseño creacional que divide la creación de un objeto en pasos. Usando el mismo proceso de construcción, puedes generar diferentes representaciones del mismo objeto.

Piensa en una fábrica de vehículos. Cuando entregan un coche, también entregan un manual. El proceso conceptual es el mismo: describir frenos, quemacocos, tablero. Lo que cambia es la implementación: el coche se arma con máquinas, el manual se redacta en un procesador de texto. Mismo procedimiento, distintas representaciones.

¿Para qué sirve el patrón Builder? Sirve para crear objetos que comparten un proceso de construcción pero tienen variaciones en sus piezas, sin saturar tu código con clases o parámetros innecesarios.

¿Qué problema resuelve Builder en la producción de coches?

Imagina este requerimiento: los coches Sedan tendrán versiones CVT y Signature en cada familia (Mastodon y Rhino), y cada versión modifica dos elementos: el color y el número de bolsas de aire.

El equipo propone tres soluciones antes de llegar a Builder, y cada una tiene su costo.

¿Por qué Factory Method se queda corto aquí?

La regla de Factory es clara: nuevo producto, nueva clase fábrica. Aplicada al problema, terminarías con clases como:

• SedanMastodonSignature.
• SedanMastodonCVT.
• HatchbackMastodonSignature.
• HatchbackRhinoCVT.

Y así sucesivamente. Multiplicas clases producto y clases fábrica. Resuelve el problema, sí, pero no es óptimo.

¿Y usar Abstract Factory?

Otra propuesta: que la fábrica de cada familia retorne todas las versiones. Tu SedanFactory tendría métodos como createMastodonSignature, createMastodonCVT, createRhinoSignature y createRhinoCVT. Cuatro métodos fábrica solo para Sedan.

Funciona, pero implica modificar la interfaz de Abstract Factory y declarar muchísimas clases. Mucho trabajo.

¿Qué es el constructor telescópico?

La tercera idea es hacer que el constructor reciba todos los elementos de personalización como parámetros. Aquí aparece el constructor telescópico: un método con 10 o 12 parámetros donde el orden importa y muchos pueden estar vacíos.

¿Qué es un constructor telescópico? Es un constructor con demasiados parámetros, donde recordar el orden y manejar valores por defecto se vuelve un dolor de cabeza. Builder existe en parte para evitarlo.

Puedes mitigarlo pasando un objeto con propiedades, pero el manejo de casos de uso sigue siendo frágil.

¿Cómo se implementa el patrón Builder paso a paso?

La propuesta de Builder se organiza en cuatro componentes que conviene tener claros antes de tocar código.

1. Declarar una clase base o interfaz que defina los pasos generales de creación del producto. Es la línea de producción: agregar llantas, agregar asientos, agregar bolsas de aire. Aquí defines qué pasos existen, no cómo se ejecutan.
2. Implementar builders concretos que ofrezcan diferentes versiones de esos pasos. Tendrías un SedanBuilder y un HatchbackBuilder, y cada uno interpreta los pasos según el tipo de vehículo que construye.
3. Implementar productos concretos que puedan ser retornados por los builders. Y aquí viene un detalle clave: no tienen que seguir una clase base o interfaz común. A diferencia de Factory Method, donde siempre retornabas el tipo base (un Car), Builder te permite retornar productos específicos sin forzar una jerarquía. Si quieres usar una clase base, también puedes.
4. Implementar una clase directora que conozca el orden en el que se llaman los pasos de construcción. La directora dice: "yo sé cómo se arma una Signature, no importa si es Sedan o Hatchback; tú, builder, implementa los pasos como quieras, yo coordino el orden".

¿Cuál es la diferencia entre Builder y Factory? Factory crea un producto con una sola llamada y suele retornar un tipo base común. Builder construye el producto en pasos secuenciales y puede retornar productos concretos sin clase base compartida.

¿Cuándo conviene aplicar Builder?

Úsalo cuando tu objeto tiene muchas configuraciones posibles, cuando el proceso de construcción es el mismo pero las piezas cambian, o cuando estás a punto de escribir un constructor con más de cuatro parámetros.

En el caso de los coches, Builder evita la explosión de clases de Factory, la sobrecarga de métodos de Abstract Factory y la fragilidad del constructor telescópico. Mismo proceso, distintas representaciones, código limpio.

¿Ya identificaste un objeto en tu proyecto que se beneficiaría de Builder? Cuéntame en los comentarios cómo lo estás construyendo hoy.