Real Work in Constructor vs Factory Method [duplicate]

1

Così ho fatto molte letture / ricerche su codice / design pulito, OOAD, refactoring, TDD, ecc. Sto solo cercando di migliorare i miei progetti per essere più facili da estendere e mantenere. Una cosa che emerge molto spesso è evitare di fare "lavoro reale" in un costruttore.

Non invierò qui le risorse, ma nomi come Misko Hevery, Bob Martin, ecc. sembrano raccomandare di evitare di fare molto lavoro nel costruttore (una rapida ricerca su Google restituisce una serie di articoli). La mia domanda non è tanto il modo in cui farlo accadere, ma PERCHÉ? Perché dovrei scegliere di utilizzare un metodo di produzione statico? Perché questo migliora la testabilità (come si dice)?

Un esempio di ciò di cui sto parlando è qui:

public class ConstructorObject
{
    public int Value { get; }

    public ConstructorObject()
    {
      // do work (e.g. calculate divisors, GCD for array, etc.) to calculate value
      Value = value;
    }
}

public class FactoryMethodObject
{
    public int Value { get; }

    public static Create()
    {
        // do work (e.g. calculate divisors, GCD for array, etc.) to calculate value
        return new FactoryMethodObject(value);
    }

    private FactoryMethodObject(int value)
    {
        Value = value;
    }
}

Per me, questi sembrano offrire gli stessi vantaggi e svantaggi. Quindi sto cercando di capire perché ... Grazie!

    
posta keelerjr12 19.06.2018 - 20:40
fonte

2 risposte

1

Why would I choose to use a static factory method?

Fornisce un singolo posto per modificare la costruzione degli oggetti, se si vuole cambiare l'implementazione, è possibile cambiare il metodo di fabbrica e tutto utilizzerà la nuova implementazione, poiché i metodi di fabbrica di utilizzo restituiscono quasi sempre un'interfaccia.

Un secondo motivo è nascondere la tipizzazione concreta implementando un'interfaccia per ragioni simili a quelle sopra. Permette di isolare il codice e ridurre l'area della superficie di interazione. Da qui il consiglio "dipendere da interfacce non concrete"

Why does this improve test-ability (as they say)?

L'isolamento migliorato migliora la capacità di test.

Migliora la capacità di test in quanto ti dà un posto conveniente per iniettare mock; sostituire il metodo statico con uno che restituisce una simulazione. Puoi semplicemente modificare un'importazione o utilizzare la direttiva e all'improvviso il tuo codice utilizza la versione derisoria.

To me, these appear to provide the same advantages and disadvantages. ...

Perché il codice che mostri non usa interfacce, che sono un concetto chiave in OOA & D.

    
risposta data 19.06.2018 - 20:56
fonte
0

Una ragione è questa: Cos'è l'iniezione del costruttore? ... Se vuoi fare correttamente DI, non puoi raddoppiare i tuoi costruttori. Si può discutere di contenitori IOC che ti costringono a questo schema per evitare il modello del costruttore.

Un altro motivo è la scalabilità, alcune delle nostre fabbriche iniettano una dozzina di altre fabbriche, se usassi un approccio basato sul costruttore dovrei risolvere quei riferimenti ogni volta che chiamavo la fabbrica complessa che trasforma il mio codice in poltiglia.

    
risposta data 19.06.2018 - 21:48
fonte

Leggi altre domande sui tag