Rappresenta le dipendenze di oggetti complessi

Devi guardare tutti dei modelli di creazione di oggetti comuni e fare una valutazione basata sullo stato della tua logica, il tempo necessario per implementare la modifica e così via. Inoltre, piuttosto che gli oggetti partecipanti sanno come costruirsi a vicenda, dovresti considerare Inversion of Control.

È difficile essere specifici senza ulteriori informazioni, ma dato che si sta parlando di un grafico complesso, penserei che Abstract Factory o Builder sarebbe più utile qui che solo una semplice Factory, a seconda di quanto diversi sono i diversi scenari.

Se hai delle decisioni iniziali per fare quella creazione di influenza del grafico ma le differenze sono sfumature, guarda Builder ... in particolare se ci sono alcune differenze strutturali tra i "prodotti" (come, alcuni oggetti partecipanti sono opzionali o in alcuni scenari gli oggetti partecipanti trascinano in un altro gruppo di collaboratori).

Se le differenze tra gli scenari sono più distinte / elaborate e prendono la forma di "famiglie" di oggetti che dovrebbero essere usati insieme, guarda a Abstract Factory con alcune diverse implementazioni di fabbrica.

Se in realtà hai solo alcuni specifici sapori di questo grafico e vuoi scegliere e scegliere tra loro dinamicamente, potresti essere in grado di andare con Prototype; considera l'implementazione corrente come un prototipo, codifica le tue implementazioni alternative come un altro prototipo e clona il prototipo appropriato secondo necessità.

Sposterei tutte le logiche di costruzione di oggetti da Outer in una classe diversa usando Factory_pattern .

I costruttori delle classi di dominio "Esterno" e "Interno" ottengono tutti i parametri figli richiesti

public Outer(Inner inner)
{
    _inner = inner;
}

e la fabbrica crea gli articoli per te:

public class OuterFactory
{
    // Existing behaviour - concrete Inner instantiation is hard coded
    public virtual Outer createOuter(CreationParameters parameters)
    {
        Inner _inner = createInner(parameters);
        Outer outer = new Outer(inner);

        return outer;           
    }

    public virtual Inner createInner(CreationParameters parameters)
    {
        Inner _inner = new Inner();     
        return _inner;          
    }
}

Se hai bisogno di una classe interna diversa puoi creare facilmente un nuovo stabilimento che deriva dalla fabbrica di base:

public class MySpecialOuterFactory : OuterFactory
{
    public overrrde Inner createInner(CreationParameters parameters)
    {
        Inner _inner = new SpecialInner();      
        return _inner;          
    }
}

Un approccio con la riflessione potrebbe funzionare bene qui.

Quindi, supponendo che sia ok per impostare il grafico nel modo predefinito, e quindi impostare i valori che si desidera sovrascrivere dopo (che richiede la mutevolezza dei propri oggetti, ovviamente):

Avere il grafico degli oggetti impostato nel modo predefinito. Quindi utilizzare la riflessione per percorrere il grafico dell'oggetto. Per ogni oggetto che trovi nel grafico, controlla le proprietà rappresentate nella tua struttura helper user_overrides per l'override. Se trovi una corrispondenza, imposta la proprietà sul nuovo valore (di nuovo, usando la riflessione).

A seconda del tuo scenario esatto, potresti essere in grado di eguagliare i tipi di classe nella tua struttura user_overrides ; in alternativa, potrebbe essere necessario memorizzare i keypath, con cui intendo qualcosa che rappresenta il percorso verso una determinata classe nel grafico dell'oggetto.

Potrebbe essere necessario prestare attenzione all'ordine in cui si ignorano le cose nella struttura ad albero.

Ci sono un sacco di informazioni là fuori sulla riflessione .

La tua descrizione di user_overrides inizia a sembrare un po 'come il modello di strategia - dove oggetti al di fuori della gerarchia passare una strategia ( richiamata ) per creare la dipendenza ..

esempio in pseudocode

type OuterType
{
    private inner : InnerType

    // Existing behaviour - concrete Inner instantiation is hard coded
    OuterConstructor()
    {
        _inner = new Inner()
    }

    // Strategy pattern, instantiation strategy is passed from outside as
    // a callback function which returns an Inner instance
    OuterConstructor(func() innerBuilderCallback)
    {
        _inner = innerBuilderCallback()
    }
}

Cosa succede se Inner ha anche una dipendenza che vuoi esporre con una strategia di istanziazione? Non devi passare entrambe le strategie al costruttore Outer , dal momento che quella strategia stessa "incatena" la strategia nidificata

void Foo()
{
    func innerBuilderCallback = lambda: new Inner(lambda: new InnerDependency());

    var outer = new Outer(innerBuilderCallback);
}

A seconda di quanto profonda è la tua gerarchia, potresti scoprire che ti ritroverai con alcune di queste strategie di callback che diventano un po 'difficili da gestire. In tal caso, incapsula l'intero processo in un oggetto Factory .