Creazione di oggetti grandi e immutabili senza utilizzare costruttori con lunghi elenchi di parametri

Ho alcuni oggetti grandi (più di 3 campi) che possono e devono essere immutabili. Ogni volta che mi imbatto in quel caso tendo a creare abomini di costruttori con lunghi elenchi di parametri.

Non sembra giusto, è difficile da usare e la leggibilità ne soffre.

È anche peggio se i campi sono una sorta di tipo di raccolta come gli elenchi. Un sempliceaddSibling(S s) faciliterebbe così tanto la creazione dell'oggetto ma rende l'oggetto mutabile.

Cosa usate in questi casi?

Sono su Scala e Java, ma penso che il problema sia indipendente dal linguaggio fintanto che il linguaggio è orientato agli oggetti.

Soluzioni a cui riesco a pensare:

1. "Abomini costruttori con lunghi elenchi di parametri"
2. Il modello Builder

Bene, vuoi sia un oggetto più facile da leggere che immutabile una volta creato?

Penso che un'interfaccia fluente FATTA CORRETTAMENTE ti aiuterebbe.

Sarebbe simile a questo (esempio puramente inventato):

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

Ho scritto "FATTO CORRETTAMENTE" in grassetto perché la maggior parte dei programmatori Java sbagliano le interfacce fluenti e inquinano i loro oggetti con il metodo necessario per costruire l'oggetto, che ovviamente è completamente sbagliato.

Il trucco è che solo il metodo build () crea effettivamente un Foo (quindi Foo può essere immutabile).

FooFactory.create () , doveXXX (..) e withXXX (..) creano "qualcos'altro".

Quel qualcos'altro potrebbe essere una FooFactory, ecco un modo per farlo ...

You FooFactory sarebbe simile a questo:

// 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 );
}

In Scala 2.8, è possibile utilizzare parametri denominati e predefiniti, nonché il copymetodo su una classe case. Ecco un po 'di codice di esempio:

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))

Bene, considera questo su 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))

Questo ovviamente ha la sua parte di problemi. Ad esempio, prova a creare espousee Option[Person], quindi a far sposare due persone. Non riesco a pensare a un modo per risolverlo senza ricorrere a un private vare / o un privatecostruttore più una fabbrica.

Ecco un paio di altre opzioni:

opzione 1

Rendi l'implementazione stessa mutevole, ma separa le interfacce che espone a mutabili e immutabili. Questo è tratto dal design della libreria 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
  }
}

opzione 2

Se la tua applicazione contiene un insieme ampio ma predefinito di oggetti immutabili (ad esempio oggetti di configurazione), potresti prendere in considerazione l'utilizzo del framework Spring .

È utile ricordare che esistono diversi tipi di immutabilità . Per il tuo caso, penso che l'immutabilità "ghiacciolo" funzionerà molto bene:

Immutabilità del ghiacciolo: è ciò che chiamo capricciosamente un leggero indebolimento dell'immutabilità di una sola scrittura. Si potrebbe immaginare un oggetto o un campo che è rimasto mutabile per un po 'durante la sua inizializzazione e poi è stato “congelato” per sempre. Questo tipo di immutabilità è particolarmente utile per oggetti immutabili che fanno riferimento circolarmente l'un l'altro, o oggetti immutabili che sono stati serializzati su disco e dopo la deserializzazione devono essere "fluidi" fino a quando non viene completato l'intero processo di deserializzazione, a quel punto tutti gli oggetti possono essere congelato.

Quindi inizializzi il tuo oggetto, quindi imposti un flag "freeze" di qualche tipo che indica che non è più scrivibile. Preferibilmente, nasconderai la mutazione dietro una funzione in modo che la funzione sia ancora pura per i client che consumano la tua API.

Puoi anche fare in modo che gli oggetti immutabili espongano metodi che sembrano mutatori (come addSibling) ma lascia che restituiscano una nuova istanza. Questo è ciò che fanno le collezioni Scala immutabili.

Lo svantaggio è che potresti creare più istanze del necessario. È anche applicabile solo quando esistono configurazioni valide intermedie (come un nodo senza fratelli che è ok nella maggior parte dei casi) a meno che non si voglia trattare con oggetti parzialmente costruiti.

Ad esempio, un bordo del grafico che non ha ancora destinazione non è un bordo del grafico valido.

Considera quattro possibilità:

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");

Per me, ciascuno di 2, 3 e 4 è adattato a una situazione diversa. Il primo è difficile da amare, per i motivi citati dall'OP, ed è generalmente sintomo di un design che ha subito qualche creep e necessita di qualche refactoring.

Quello che sto elencando come (2) è buono quando non c'è uno stato dietro la "fabbrica", mentre (3) è il design di scelta quando c'è uno stato. Mi trovo a usare (2) invece di (3) quando non voglio preoccuparmi dei thread e della sincronizzazione, e non devo preoccuparmi di ammortizzare alcune costose impostazioni sulla produzione di molti oggetti. (3), d'altra parte, viene richiamato quando il lavoro reale va nella costruzione della fabbrica (impostazione da uno SPI, lettura dei file di configurazione, ecc.).

Infine, la risposta di qualcun altro ha menzionato l'opzione (4), dove hai molti piccoli oggetti immutabili e lo schema preferibile è quello di ottenere notizie da quelli vecchi.

Nota che non sono un membro del "fan club dei modelli" - certo, alcune cose meritano di essere emulate, ma mi sembra che assumano una vita inutile una volta che le persone danno loro nomi e cappelli divertenti.

Un'altra possibile opzione è il refactoring per avere meno campi configurabili. Se gruppi di campi funzionano solo (principalmente) tra loro, raccogliili nel loro piccolo oggetto immutabile. I costruttori / builder di quell'oggetto "piccolo" dovrebbero essere più gestibili, così come il costruttore / builder per questo oggetto "grande".

Uso C # e questi sono i miei approcci. Tener conto di:

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.
}

Opzione 1. Costruttore con parametri opzionali

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

Usato come ad es new Foo(5, b: new Bar(whatever)). Non per le versioni Java o C # precedenti alla 4.0. ma vale comunque la pena mostrare, in quanto è un esempio di come non tutte le soluzioni siano indipendenti dalla lingua.

Opzione 2. Costruttore che accetta un singolo oggetto parametro

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() { }
}

Esempio di utilizzo:

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

C # da 3.0 in poi lo rende più elegante con la sintassi dell'inizializzatore di oggetti (semanticamente equivalente all'esempio precedente):

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

Opzione 3:
ridisegna la tua classe in modo da non richiedere un numero così elevato di parametri. Potresti suddividere le sue responsabilità in più classi. Oppure passare i parametri non al costruttore ma solo a metodi specifici, su richiesta. Non sempre fattibile, ma quando lo è, vale la pena farlo.