Reimplement a class method in a different assembly

I have a configuration class that loads configuration property values from different sources and allows to set property values programmatically.

At the moment, it tries loading configuration values in this order:

• Environment variables
• App.config file
• settings.json file
• Use the defaults and allow users to change properties in their own code

Since most users are setting the configuration programmatically and I also want to get rid of the Microsoft.Extensions.Configuration dependency as much as possible, I want to move the first three cases in a different assembly, to be depended on explicitly if users want to load configuration properties, for instance, from an App.config file.

Ideally, I'd like the change to be transparent for users, so that they don't have to change their existing code.

What my config class does at the moment is, in its constructor, something like:

public Config()
{
    InitializeDefaults();
    ReadEnvironmentVariables();
    ReadAppConfig();
}

Is there a way to provide an empty implementation of ReadEnvironmentVariables and ReadAppConfig in my existing assembly and replace it with the actual implementation in the new assembly, so that if the application has the new assembly in its dependencies it uses the actual implementation, otherwise it defaults to an empty method?

I can probably do this by #defining a constant in my new assembly and doing

#if CONFIG_EXTENSION
    ReadEnvironmentVariables();
    ReadAppConfig();
#endif

But i was wondering if there was a better way to achieve this.

Edit to clarify: I don't have a dependency container available, so I can't use dependency injection, because the class is part of a library and I don't want to assume users use a dependency container.

A good way to solve this problem is to use .NET dependency injection. Basically you do not program against a class, but against an interface and inject an implementation in your classes.

public interface IConfigFactory
{
    IConfig GetConfiguration();
}

public interface IConfig
{
    bool TryGetValue<T>(string key, out T value);
}

IConfigFactory.GetConfiguration() is then responsible to load the configuration only at the first call and return the same instance at subsequent calls. You could also add a Reset() method forcing to reload a fresh version of the config at the next call.

Then in one of your classes you inject it like this

public class ExamplePrintService
{
    private readonly IConfig _config;

    public ExamplePrintService (IConfigFactory configFactory)
    {
        _config = configFactory.GetConfiguration();
    }

    public void Print(IDocument doc)
    {
        double leftMargin = _config.TryGetValue<double>("leftmargin", out var lm)
            ? lm
            : 9.0;
        ...
    }
}

If you are using an IoC container, you would then register an implementation of IConfigFactory as singleton. At the start of the application you can then choose to register different implementations. The rest of the application does not need to care about which implementation is used or how the config is retrieved.

As @Ralf pointed out, you can use this pattern without an IoC container. An IoC container can be configured in a central place and then injects the dependencies automatically. Without it you will have to inject the dependencies manually.

You could also have different levels of abstraction. E.g. an IPrintConfig interface could expose concrete configuration properties an rely on the abstract interfaces shown above.

Are you using a DI container or any form of DI (Dependency Injection)?

How does a consumer get an instance of the Config class?

If you don't have some form of DI support you might consider the following:

• Add a private field in the Config class that is of the Action delegate type
• Initialize the Action to a default implementation, e.g. maybe calling the existing ReadEnvironmentVariables() and ReadAppConfig() methods
• Replace calling the existing methods with invoking the Action, i.e. a level of indirection has been added
• Add a constructor that accepts an Action and sets the private field
• In the new assembly create a static method that returns a Config object created via the constructor that injects a different Action

The exact details can vary but hopefully this example shows the basic idea.