Construir objetos grandes e inmutables sin usar constructores que tengan listas de parámetros largas

Tengo algunos objetos grandes (más de 3 campos) que pueden y deben ser inmutables. Cada vez que me encuentro con ese caso tiendo a crear abominaciones de constructores con largas listas de parámetros.

No se siente bien, es difícil de usar y la legibilidad se ve afectada.

Es incluso peor si los campos son algún tipo de colección como listas. Un simple addSibling(S s)facilitaría mucho la creación del objeto pero hace que el objeto sea mutable.

¿Qué usan ustedes en tales casos?

Estoy en Scala y Java, pero creo que el problema es agnóstico del lenguaje siempre que el lenguaje esté orientado a objetos.

Soluciones en las que puedo pensar:

1. "Abominaciones de constructores con largas listas de parámetros"
2. El patrón del constructor

Bueno, ¿quieres un objeto más fácil de leer e inmutable una vez creado?

Creo que una interfaz fluida CORRECTAMENTE HECHA te ayudaría.

Se vería así (ejemplo puramente inventado):

final Foo immutable = FooFactory.create()
    .whereRangeConstraintsAre(100,300)
    .withColor(Color.BLUE)
    .withArea(234)
    .withInterspacing(12)
    .build();

Escribí "CORRECTAMENTE HECHO" en negrita porque la mayoría de los programadores de Java se equivocan en las interfaces fluidas y contaminan su objeto con el método necesario para construir el objeto, lo cual, por supuesto, es completamente incorrecto.

El truco es que solo el método build () realmente crea un Foo (por lo tanto, tu Foo puede ser inmutable).

FooFactory.create () , dondeXXX (..) y withXXX (..) todos crean "algo más".

Que algo más puede ser un FooFactory, aquí hay una forma de hacerlo ...

Tu FooFactory se vería así:

// Notice the private FooFactory constructor
private FooFactory() {
}

public static FooFactory create() {
    return new FooFactory();
}

public FooFactory withColor( final Color col ) {
    this.color = color;
    return this;
}

public Foo build() {
    return new FooImpl( color, and, all, the, other, parameters, go, here );
}

En Scala 2.8, puede usar parámetros con nombre y predeterminados, así como el copymétodo en una clase de caso. Aquí hay un código de ejemplo:

case class Person(name: String, age: Int, children: List[Person] = List()) {
  def addChild(p: Person) = copy(children = p :: this.children)
}

val parent = Person(name = "Bob", age = 55)
  .addChild(Person("Lisa", 23))
  .addChild(Person("Peter", 16))

Bueno, considere esto en Scala 2.8:

case class Person(name: String, 
                  married: Boolean = false, 
                  espouse: Option[String] = None, 
                  children: Set[String] = Set.empty) {
  def marriedTo(whom: String) = this.copy(married = true, espouse = Some(whom))
  def addChild(whom: String) = this.copy(children = children + whom)
}

scala> Person("Joseph").marriedTo("Mary").addChild("Jesus")
res1: Person = Person(Joseph,true,Some(Mary),Set(Jesus))

Esto tiene su parte de problemas, por supuesto. Por ejemplo, intente hacer espousey Option[Person], y luego casar a dos personas entre sí. No puedo pensar en una forma de resolver eso sin recurrir a un private vary / o un privateconstructor más una fábrica.

Aquí hay un par de opciones más:

Opción 1

Haga que la implementación en sí sea mutable, pero separe las interfaces que expone a mutables e inmutables. Esto se toma del diseño de la biblioteca Swing.

public interface Foo {
  X getX();
  Y getY();
}

public interface MutableFoo extends Foo {
  void setX(X x);
  void setY(Y y);
}

public class FooImpl implements MutableFoo {...}

public SomeClassThatUsesFoo {
  public Foo makeFoo(...) {
    MutableFoo ret = new MutableFoo...
    ret.setX(...);
    ret.setY(...);
    return ret; // As Foo, not MutableFoo
  }
}

opcion 2

Si su aplicación contiene un conjunto grande pero predefinido de objetos inmutables (por ejemplo, objetos de configuración), puede considerar usar el marco Spring .

Es útil recordar que existen diferentes tipos de inmutabilidad . Para su caso, creo que la inmutabilidad de "paleta" funcionará muy bien:

Inmutabilidad de la paleta: es lo que llamo caprichosamente un ligero debilitamiento de la inmutabilidad de una sola escritura. Uno podría imaginar un objeto o un campo que permaneció mutable por un tiempo durante su inicialización, y luego se "congeló" para siempre. Este tipo de inmutabilidad es particularmente útil para objetos inmutables que se referencian circularmente entre sí, o los objetos inmutables que se han serializado en el disco y después de la deserialización deben ser "fluidos" hasta que finalice todo el proceso de deserialización, momento en el que todos los objetos pueden ser congelado.

Así que inicializas tu objeto, luego colocas un indicador de "congelación" de algún tipo que indica que ya no se puede escribir. Preferiblemente, escondería la mutación detrás de una función para que la función siga siendo pura para los clientes que consumen su API.

También puede hacer que los objetos inmutables expongan métodos que parezcan mutantes (como addSibling) pero dejar que devuelvan una nueva instancia. Eso es lo que hacen las inmutables colecciones Scala.

La desventaja es que puede crear más instancias de las necesarias. También solo es aplicable cuando existen configuraciones intermedias válidas (como algún nodo sin hermanos, lo cual está bien en la mayoría de los casos) a menos que no desee tratar con objetos parcialmente construidos.

Por ejemplo, un borde de gráfico que aún no tiene destino no es un borde de gráfico válido.

Considere cuatro posibilidades:

new Immutable(one, fish, two, fish, red, fish, blue, fish); /*1 */

params = new ImmutableParameters(); /*2 */
params.setType("fowl");
new Immutable(params);

factory = new ImmutableFactory(); /*3 */
factory.setType("fish");
factory.getInstance();

Immutable boringImmutable = new Immutable(); /* 4 */
Immutable lessBoring = boringImmutable.setType("vegetable");

Para mí, cada uno de 2, 3 y 4 se adapta a una situación diferente. El primero es difícil de amar, por las razones citadas por el OP, y generalmente es un síntoma de un diseño que ha sufrido algunos problemas y necesita una refactorización.

Lo que estoy enumerando como (2) es bueno cuando no hay un estado detrás de la 'fábrica', mientras que (3) es el diseño de elección cuando hay un estado. Me encuentro usando (2) en lugar de (3) cuando no quiero preocuparme por los hilos y la sincronización, y no necesito preocuparme por amortizar una configuración costosa sobre la producción de muchos objetos. (3), por otro lado, se solicita cuando se realiza un trabajo real en la construcción de la fábrica (configuración desde un SPI, lectura de archivos de configuración, etc.).

Finalmente, la respuesta de otra persona mencionó la opción (4), donde tiene muchos pequeños objetos inmutables y el patrón preferible es obtener noticias de los antiguos.

Tenga en cuenta que no soy miembro del 'club de fans de patrones'; claro, vale la pena emular algunas cosas, pero me parece que adquieren una vida inútil una vez que la gente les da nombres y sombreros divertidos.

Otra opción potencial es refactorizar para tener menos campos configurables. Si los grupos de campos solo funcionan (en su mayoría) entre sí, reúnalos en su propio pequeño objeto inmutable. Los constructores / constructores de ese objeto "pequeño" deberían ser más manejables, al igual que el constructor / constructor de este objeto "grande".

Yo uso C #, y estos son mis enfoques. Considerar:

class Foo
{
    // private fields only to be written inside a constructor
    private readonly int i;
    private readonly string s;
    private readonly Bar b;

    // public getter properties
    public int I { get { return i; } }
    // etc.
}

Opción 1. Constructor con parámetros opcionales

public Foo(int i = 0, string s = "bla", Bar b = null)
{
    this.i = i;
    this.s = s;
    this.b = b;
}

Usado como por ejemplo new Foo(5, b: new Bar(whatever)). No para las versiones de Java o C # anteriores a la 4.0. pero vale la pena mostrarlo, ya que es un ejemplo de cómo no todas las soluciones son independientes del idioma.

Opción 2. Constructor tomando un único objeto de parámetro

public Foo(FooParameters parameters)
{
    this.i = parameters.I;
    // etc.
}

class FooParameters
{
    // public properties with automatically generated private backing fields
    public int I { get; set; }
    public string S { get; set; }
    public Bar B { get; set; }

    // All properties are public, so we don't need a full constructor.
    // For convenience, you could include some commonly used initialization
    // patterns as additional constructors.
    public FooParameters() { }
}

Ejemplo de uso:

FooParameters fp = new FooParameters();
fp.I = 5;
fp.S = "bla";
fp.B = new Bar();
Foo f = new Foo(fp);`

C # de 3.0 en adelante lo hace más elegante con la sintaxis del inicializador de objetos (semánticamente equivalente al ejemplo anterior):

FooParameters fp = new FooParameters { I = 5, S = "bla", B = new Bar() };
Foo f = new Foo(fp);

Opción 3:
Rediseñe su clase para que no necesite una cantidad tan grande de parámetros. Podría dividir sus responsabilidades en varias clases. O pase los parámetros no al constructor, sino solo a métodos específicos, bajo demanda. No siempre es viable, pero cuando lo es, vale la pena hacerlo.