Qual è il modo corretto (o preferito) per configurare una classe factory statica?

1

Primo stack SE,

Sto lavorando su una grande porzione del vecchio codice Java e sto trovando tonnellate di duplicati e oggetti configurati / creati in modo incoerente a causa di diversi autori, livelli di abilità, ecc.

Ho implementato alcuni modelli di factory statici e sto avendo un dibattito su come rendere configurabile la fabbrica.

MODIFICA: per suggerimenti di commenti,

Opzione A:

public final class TacoFactory {

    private static int defaultCheese = 0;

    private TacoFactory() {}

    public static Taco createTaco(int cheese) {}

    public static Taco createDefaultTaco() { createTaco(defaultCheese); }

    public static synchronized void configure(int cheese) { 
        this.defaultCheese = cheese; 
    }
}

Opzione B:

public final class TacoFactory {

    public static int defaultCheese = 0;

    private TacoFactory() {}

    public static Taco createTaco(int cheese) {}

    public static Taco createDefaultTaco() { createTaco(defaultCheese); }
}

Opzione C: Qualche modo / modello elitario che google-fu deve ancora darmi. Se c'è qualche buona documentazione su questo modello, per favore condividi. :)

Opzione D: non importa e / o non è specificato.

Opzione E: Pattern Builder, anche se ho espresso le mie preoccupazioni sul motivo per cui non penso che questo si adatti al mio caso di uso sulla risposta che lo suggerisco di seguito.

class Taco {
    private final int cheese;
    private final int beef;

    Taco(int cheese, int beef) {
        this.cheese = cheese;
        this.beef = beef;
    }
}

class TacoBuilder {
    private int cheese = 0; 

    TacoBuilder setCheese(int cheese) {
        this.cheese = cheese;
        return this;
    }

    TacoBuilder setBeef(int beef) {
        this.beef = beef;
        return this;
    }

    Taco build() {
        return new Taco(a, b);
    }
}

Foo foo = new FooBuilder().setA("a").build();
    
posta finleyarcher 31.08.2017 - 00:24
fonte

2 risposte

3

L'opzione B sembra altamente preferibile per una fabbrica statica, in quanto consentire la configurazione di una classe statica richiede solo problemi.

  • In un ambiente a thread singolo si vedranno ancora problemi, in cui il modulo A configura il factory, ma il modulo B si aspettava una configurazione diversa. Questo è particolarmente importante quando non "possiedi" tutto il codice client (comunque importante se lo fai comunque).

  • In un ambiente multi-thread (anche se si synchronize dei metodi), si potrebbe avere un thread modificare il valore predefinito mentre un altro sta cercando di ottenere il valore predefinito e finire con un comportamento non deterministico (dovuto alle condizioni di gara).

Se si desidera una fabbrica configurabile, renderla non statica. Ciò renderà il codice riutilizzabile. Se è configurabile e statico, nessuno può usarlo, perché non possono contare su altri programmatori nella stessa base di codice che cambiano la configurazione else-where.

    
risposta data 31.08.2017 - 18:31
fonte
1

L'opzione A sembra la più vicina a quello che mi aspetterei. Sembra che tu abbia provato a implementare il modello Builder per la tua fabbrica, ma non sembra fornire un'interfaccia completa.

Raccomando di leggere la risposta di Vitali Fedorenko a questa domanda e quindi di seguire la opzione 5 da quella risposta.

    
risposta data 31.08.2017 - 09:33
fonte