While most dependency initialization can be setup at compile time, some dependencies need to be initialized at runtime. How can this be done? Let's try a couple of approaches. As an example lets think about an Excel worksheet, where we need to provide a path, worksheet name and the existence of a header row to initialize the Excel worksheet object. I'll use StructureMap in this example.

One way this can be accomplished is by creating an interface that has a "init" method:

public interface IExcelWorksheet
{
    void Init(string path, string worksheet, bool headerRow);
    IDataReader GetReader();
}

public class ExcelWorksheet : IExcelWorksheet
{
    public void Init(string path, string worksheet, bool headerRow)
    {
        // Initialize...
    }

    public IDataReader GetReader()
    {
        // Return a reader
    }
}

Then we can register this and use it in a service:

ObjectFactory.Initialize(x => x.For<IExcelWorksheet>().Use<ExcelWorksheet>());

ExcelService excelService = ObjectFactory.GetInstance<ExcelService>();
excelService.DoSomething(path, worksheet, headerRow);

public class ExcelService
{
    private IExcelWorksheet _worksheet;

    public ExcelService(IExcelWorksheet worksheet)
    {
        _worksheet = worksheet;
    }

    public void DoSomething(string path, string worksheet, bool headerRow)
    {
        _worksheet.Init(path, worksheet, headerRow);
        IDataReader reader = _worksheet.GetReader();
        // Do something....
    }
}

First issue; implementation details are leaking out through the interface. Plus the path, worksheet and header row flag are required for this object to function properly but the requirement is not enforced or communicated clearly enough. It could be enforced via a private flag and exception but this would occur at runtime and is IMO a poor design since the intent is buried in the object. I shouldn't have to dig into the object to understand its intent.

Now we could use an abstract factory approach instead to solve this problem:

public interface IDataSource
{
    IDataReader GetReader();
}

public interface IExcelWorksheetFactory
{
    IDataSource Create(string path, string worksheet, bool headerRow);
}

public class ExcelWorksheetFactory : IExcelWorksheetFactory
{
    public IDataSource Create(string path, string worksheet, bool headerRow)
    {
        return new ExcelWorksheet(path, worksheet, headerRow);
    }
}

public class ExcelWorksheet : IDataSource
{
    public ExcelWorksheet(string path, string worksheet, bool headerRow)
    {
        // Initialize...
    }

    public IDataReader GetReader()
    {
        // Return a reader
    }
}

So here we've changed things up a bit. First we've put the required initialization where it should be, in the constructor, so the intent is very clear. We've also introduced the abstract factory for the Excel spreadsheet. Then we've created the concept of a "data source" which is even more abstract, does not leak implementation details, reduces coupling and enables some DRY (Since we can now have multiple "data sources" and functionality to consume those). Let's see how this can be consumed:

ObjectFactory.Initialize(x => x.For<IExcelWorksheetFactory>().Use<ExcelWorksheetFactory>());

ExcelService excelService = ObjectFactory.GetInstance<ExcelService>();
excelService.DoSomething(path, worksheet, headerRow);

public class ExcelService
{
    private IExcelWorksheetFactory _worksheetFactory;

    public ExcelService(IExcelWorksheetFactory worksheetFactory)
    {
        _worksheetFactory = worksheetFactory;
    }

    public void DoSomething(string path, string worksheet, bool headerRow)
    {
        IDataSource dataSource = _worksheetFactory.Create(path, worksheet, headerRow);
        IDataReader reader = dataSource.GetReader();
        // Do something....
    }
}

Here are some additional references:

DDD (p. 136-146) – Evans

Comments by Mark Seemann on a Stack Overflow question in regards to this scenario.