2010-09-02 17 views
6

He estado leyendo Java efectivo por Joshua Bloch y noté dos puntos que en realidad he encontrado en mi trabajo.Inmutabilidad y legibilidad

Punto 1: Haciendo métodos setter para hacer el código más legible. En su ejemplo, tenemos una clase con un constructor ridículamente enorme. Cuando las personas instancian la clase, es difícil saber qué está pasando con todos los parámetros. Por lo tanto, se sugirió hacer un constructor minimalista y tienen métodos setter para todas las otras opciones, así que en vez de ...

MyClass clazz = new MyClass (a, b, c, d, e, f, g) ;

que iba a escribir ....

MiClase clazz = new MyClass (a, b, c );
clazz.setDitto (d);
clazz.setEcho (e);
clazz.setFunzies (f);
clazz.setGumballs (g);

Que, como un gran defensor del código legible, me gustó mucho.

Punto 2: En general, sugirió tener clases inmutables. Él profundiza sobre por qué tener clases inmutables es mucho mejor que tener una clase que podría estar en varios estados diferentes. Definitivamente puedo decir que me vendió la idea, y no puedo esperar a que la mayoría de las clases que escribo sean inmutables, excepto ...

¿Qué sucede cuando tienes una clase inmutable con un gran constructor? ? No puedes hacer métodos setter para eso; eso rompería la inmutabilidad. Traté de hojear el resto del libro, pero no creo que cubra una solución para esto.

Existe la posibilidad de realizar métodos de creación de uso único, pero el hecho de que un método de creación esté disponible para una clase que supuestamente es inmutabilidad es desalentador, incluso si arroja una excepción si lo prueba posteriormente veces.

¿Alguien tiene alguna buena idea sobre cómo manejar este problema? Actualmente estoy enfrentando este problema en el trabajo donde tengo una clase Immutable con un gran constructor que me gustaría refactorizar a algo que sea más legible sin romper la inmutabilidad.

+0

Parecería que un concepto útil sería tener una clase mutable e inmutable derivada de una base abstracta común (que anuncia getters para todas las propiedades). El constructor de la clase inmutable podría aceptar un argumento de la clase base. Sin embargo, no estoy seguro de cómo permitir que la clase mutable sombree las propiedades abstractas de solo lectura con las de lectura y escritura, sin crear una clase intermedia que implemente las propiedades de solo lectura. – supercat

Respuesta

14

Una opción es proporcionar una clase de constructor separada que proporcione los ajustadores, que es responsable de construir el objeto real.

En la segunda edición de "Effective Java" de Bloch, el elemento 2 ilustra esto para una clase inmutable. Las ideas clave son:

  • El constructor tiene un campo mutable para cada opción.
  • El constructor pasa como como un argumento único para el constructor de la clase inmutable.
+1

+1 Los constructores con métodos encadenables en realidad mejoran la legibilidad sobre un objeto mutable con métodos "vacíos" establecidos, en mi opinión. – ColinD

+0

De acuerdo. Bloch incluye instaladores encadenables en el generador de ejemplos mencionado anteriormente. –

+0

Brillante! No puedo creer que me haya perdido eso. Estaba robando la sección de inmutabilidad, olvidé completamente volver a consultar con los constructores. – Noj

3

Introduce Parameter Object, ¿quizás? De alguna manera mueve el problema, pero tal vez de maneras útiles. Su objeto de parámetro no necesita métodos; solo contiene los datos, y los configura, en lugar de su clase real.Entonces su clase real se inicializa en el constructor a través del objeto de parámetro.

0

¿Qué hay de tener una clase base abstracta que apoya captadores pero no s etters para todos los atributos de la clase, una clase derivada "inmutable" sellada cuyo constructor acepta un objeto de clase base y una clase mutable derivada que incluye setters para todas las propiedades?

Cuestiones relacionadas