An IoC container which loads its configuration from an xml-config-file can do this.

If you are using java you can use spring-ioc for this.

The java config file for the Full service might contain this

<bean id="catalogService" class="com.mycompany.myproduct.MyFullCatalogService" scope="singleton" />

If you want to use the proxy version

<bean id="catalogService" class="com.mycompany.myproduct.MyProxyCatalogService" scope="singleton" />

Your main application just asks the container for id=”catalogService” to get the current service.

We use this model at work:

Production config.properties:
serviceClass=com.mycompany.LiveService

Development config.properties:
serviceClass=com.mycompany.MockService

spring.xml:
<bean id="service" class="${serviceClass}"/>
(with the appropriate property configurer)

Try this one too. I like it better, because you don’t end up putting class names in the configuration, which I think should speak at a different level of abstraction.

Production config.properties:
environment=production

Dev config.properties:
environment=development

<bean id="service" class="com.mycompany.ServiceSelector">
    <property name="environment" value="${environment}"/>
    <property name="liveService" ref="liveService"/>
    <property name="mockService" ref="mockService"/>
</bean>

// a proxy that decides on the class to "let through" based on the environment
class ServiceSelector {
    public void setLiveService(Service liveService) {
        this.liveService = liveService;
        updateCurrentService();
    }

    public void setMockService(Service mockService) {
        this.mockService = mockService;
        updateCurrentService();
    }

    public void setEnvironment(Environment environment) {
        this.environment = environment;
        updateCurrentService();
    }

    private void updateCurrentService() {
        if (environment == null) {
            currentService = null;
            return;
        }
        switch (environment) {
            case production:
                currentService = liveService;
                break;
            case development:
                currentService = mockService;
                break;
            default:
                throw new IllegalStateException();
        }
    }
}

If you have a large enough number of services in this situation, you can put all such services under a facade and implement one facade selector instead of many service selectors.

Another variation is to throw away the configuration file and provide the environment flag in the environment itself. It could be a JVM property defined with -Dname=value when the JVM is invoked, etc.

It depends on how you want to do it.

• Proxy pattern would enable you to switch implementation internally without exposing the details to anything else in your application. Hence you could at any time switch implementation without letting anything else in the code be aware of the switch.

• Factory pattern: Let the factory decide which implementation to create (by using a config file or factory arguments). Unlike proxy you can’t switch implementation once a class have received a created objected.

Both dependency injection and abstract factory are perfect for this. You have two implementation of one interface IService where one is implemetation itself and another is proxy. Depends on actual configuration you could either inject or construct one or another. Implementation using abstract factory is much easier: all logic to determine what to build is inside factory. To achieve this with dependency injection you could start with Composition Root, afterward define configuration for instance creation (full or proxy). This is much harder by flexible way to achieve required behaviour.