InicializaciónEnElConstructor

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Este es uno de los dos enfoques para inicializar un nuevo ejemplar de una clase, el otro es InicializaciónConSetters.

La inicialización en el constructor es un enfoque en el que se intenta garantizar que siempre se crea un ejemplar de una clase en un estado válido proporcionándole todos los colaboradores que el objeto necesita en el método usado para crear el objeto. De esta manera para crear un objeto Person que represente a una persona con nombre, apellidos y una colección de sus bares favoritos podríamos ver algo así:

# ruby
mf = Person.new('martin', 'fowler',
['Turners Oyster Bar', 'Square and Compass'])

De esta manera siempre te aseguras de que tienes un objeto en un estado razonablemente bien formado que está listo para ser usado. Es un enfoque compacto, que permite usarlo o invocar alguno de sus métodos en una sola línea, lo que significa que no necesitas una variable adicional en el código.

Declarar todos los colaboradores necesarios en el constructor deja claro qué colaboradores son necesarios, con lo que es más fácil averiguar cómo preparar la clase para su correcto funcionamiento. Será necesario tener un método constructor por cada combinación válida de colaboradores obligatorios. También suele resultar cómodo proporcionar constructores que incluyen también colaboradores opcionales pero habitualmente usados.

Este enfoque facilita diferenciar entre los atributos inmutables y los modificables, dado que los inmutables no tienen un método set para cambiar su valor, simplemente se inicializan en el constructor.

Inicialización en el constructor es mi opción preferida. Hay casos en los que es dificil preprar las cosas de esta manera y por ello ocasionalmente prefiero Inicializacion con Setters, pero casi siempre la inicialización en el constructor es la mejor opción.

¿Qué ocurre si hay un número grande de combinaciones de parámetros válidas para crear un nuevo objeto? A menudo la gente se preocupa de que habrá un número enorme de constructores si sigues este enfoque. En la mayoría de los casos esto no es preocupante – sólo hay unos pocos. Realmente sólo necesitan estar en el constructor los colaboradores obligatorios y rara vez hay más de un puñado de combinaciones de ellos.

¿Qué ocurre si hay muchos colaboradores para establecer en el constructor? Una lista larga de parámetros en el constructor, igual que una lista larga de parámetros es un OlorEnElCódigo. Normalmente cuando me encuentro con estos casos descubro que muchos de los parámetros son DataClumps y deberían ser reemplazados por un objeto que los agrupe. Dicho esto, no es del todo inusual que un constructor tenga más parámetros que otros métodos – pero son un buen lugar donde encontrar DataClumps.

¿Cómo encaja esto con la ValidaciónContextual? El contexto en este caso es el de uso básico del objeto – esencialmente un estado mínimamente útil. Probablemente con ello no será válido para ciertas actividades, pero debería ser suficiente para que sea mínimamente útil.

Artículo original: ConstructorInitialization