You should look at all of the common object creation patterns and make an assessment based upon the state of your logic, time you have to implement the change, and so forth. Also, rather than have the participating objects know how to construct each other, you should consider Inversion of Control.

Its hard to be specific without more info, but given that you are talking about a complex graph I would think that Abstract Factory or Builder would be more useful here than just a simple Factory depending on how different each of your scenarios is.

If you have some initial decisions to make that influence creation of the graph but the differences are nuances, look at Builder…particularly if there are some structural differences between the “products” (such as, some participating objects are optional or in some scenarios participating objects drag in another set of collaborators).

If the differences between the scenarios are more distinct / elaborate and take the form of “families” of objects that should be used together, look at Abstract Factory with a few different factory implementations.

If you actually just have a few specific flavors of this graph and want to pick and choose between them dynamically, you might be able to just go with Prototype; treat your current implementation as a prototype, code up your alternate implementation(s) as another prototype, and just clone the appropriate prototype as needed.

I would move all object construction logic out of Outer into a different class using the Factory_pattern.

The Constructors of domain-classes ´Outer´ and ´Inner´ get all required child parameters

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

and the factory create the items for you:

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

If you need a different inner class you can easily create a new factory that derives from the base factory:

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

An approach using reflection might work well here.

So, assuming if it’s ok to set up the graph in the default way, and then set values that you wish to override after (which requires mutability of your objects, obviously):

Have your object graph set up in the default way. Then use reflection to walk the object graph. For each object you find in the graph, check for any properties represented in your user_overrides helper structure for overriding. If you find a match, set the property to the new value (again, using reflection).

Depending on your exact scenario, you may just be able to match against class types in your user_overrides structure; alternatively, you might have to store keypaths, by which I mean something representing the route to a certain class in the object graph.

You may have to be careful about the order in which you override things in the object tree.

There’s plenty of info out there about reflection.

Your description of user_overrides is beginning to sound a bit like the strategy pattern – where objects outside of the hierarchy pass a strategy (callback) for creating the dependency..

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

What happens if Inner also has a dependency which you want to expose with an instantiation strategy? You don’t have to pass both strategies to the Outer constructor, since that strategy will itself ‘chain’ the nested strategy

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

    var outer = new Outer(innerBuilderCallback);
}

Depending on how deep your hierarchy goes, you might find that you end up with quite a few of these callback strategies which becomes a little difficult to manage. In that case, encapsulate the whole process in a Factory object.