Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

closed as not a real question by gnat, Jim G., BЈовић, Walter, GlenH7 Jan 28 '13 at 12:28

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

4 Answers

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.

share|improve this answer
    
And if you're using .NET, Unity would be a possible option. –  Carson63000 Dec 17 '12 at 19:47
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Really really usuful and well explained.We will definetly go for this option. Thanks a lot! –  Marcos Jan 28 '13 at 8:10
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.