Switch interface implementation using configuration [closed]

Question

We want to allow the same core service to be either fully implemented or, as other option, to be a proxy toward a client legacy system (via a WSDL for example).

In that way, we have both implementation (proxy & full) and we switch which one to use in the configuration of the app.

So in a nutshell, Some desired features:

• Two different implementation (proxy, full) instead of one implementation with a switch inside
• Switch implementation using configuration: dependency injection? reflection?
• Nice-to-have: the packaged delivered to the client doesn’t have to change depending on the choice between proxy or full
• Nice-to-have: Client can develop their custom implementation of the Core Interface and configure the applciation to use that one

With this background, the question is: What alternatives we have to choose one implementation or other of an interface just changing configuration?

Thanks

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.