How to decide at runtime which concrete class implementation to instantiate

[java-john]

I have a class that uses composition of interfaces. I want to be able
to allow users to decide at run-time which implementations of these
interfaces to instantiate. What is the best way to do this? Are there
any frameworks out there? Is there some design pattern for this?

For example:

public interface MyInterface {
public String getValue();
}

public class MyClass {
private MyInterface myInterface;
public MyClass() {
myInterface = new SomeRunTimeImplementationOfMyInterface();
}
}

 

[Ed Kirwan]

I have a class that uses composition of interfaces. I want to be able
to allow users to decide at run-time which implementations of these
interfaces to instantiate. What is the best way to do this? Are there
any frameworks out there? Is there some design pattern for this?

For example:

public interface MyInterface {
public String getValue();
}

public class MyClass {
private MyInterface myInterface;
public MyClass() {
myInterface = new SomeRunTimeImplementationOfMyInterface();
}
}

This usually depends on your product's configuration, which in turn
usually depends on the user's choice of product options either when the
software is run, or on the options-window during execution.

This will usually involve the software's reading a file of options when
it's started, and there are innumerable ways of doing this: Properties,
Preferences, a roll-your-XML file, etc. (Even good-ol' command-line
parameters, though not recommended.)

The point is that, whatever means is used to input these options to the
software, somewhere in the code there will be decision points based on them.

A very basic example, if you have your configuration file as a text file
specifying whether to display graphics on the user screen or not, the
configuration file might be as simple as:
graphics=off

And the code will be something like:

Class Start {
void readConfiguraionFile() {
Properties properties = new Properties();
try {
properties.load(new
FileInputStream("filename.properties"));
} catch (IOException e) {
}
String graphicsOption = properties.getProperty("graphics");
GraphicsFacade graphics = null;
if (graphicsOptions.equals("on")) {
graphics = new FullGraphicsDisplay();
} else {
graphics = new TextOnlyDisplay();
}
store(graphics);
}
}

Class SomethingElse {
void welcomeScreen() {
GraphicsFacade graphics = retrieveGraphics();
graphics.showUserWelcome();
}
}

 

[vikasvirgo169]

I have a class that uses composition of interfaces. I want to be able
to allow users to decide at run-time which implementations of these
interfaces to instantiate. What is the best way to do this? Are there
any frameworks out there? Is there some design pattern for this?

For example:

public interface MyInterface {
public String getValue();
}

public class MyClass {
private MyInterface myInterface;
public MyClass() {
myInterface = new SomeRunTimeImplementationOfMyInterface();
}
}

Hi,

You can create something like Abstract Factory pattern in which u can
create factory for your Interfaces depending upon some user parameter.

--Vikas

 

[Roedy Green]

I have a class that uses composition of interfaces. I want to be able
to allow users to decide at run-time which implementations of these
interfaces to instantiate. What is the best way to do this? Are there
any frameworks out there? Is there some design pattern for this?

You can have a look at how JCE is implement with a pluggable
interface.
See http://mindprod.com/jgloss/jce.html

another one is the way you can register additional URL handlers.
see http://mindprod.com/jgloss/protocolhandler.html

Another is the way you can register additional encodings.
http://mindprod.com/jgloss/encoding.html#ROLLYOUROWN

 

[Oliver Wong]

I have a class that uses composition of interfaces. I want to be able
to allow users to decide at run-time which implementations of these
interfaces to instantiate. What is the best way to do this? Are there
any frameworks out there? Is there some design pattern for this?

For example:

public interface MyInterface {
public String getValue();
}

public class MyClass {
private MyInterface myInterface;
public MyClass() {
myInterface = new SomeRunTimeImplementationOfMyInterface();
}
}

The most straightforward approach is something like this:

<pseudocode>
public class FactoryClass {
public Alpha createAlpha() {
if (userChoseAlphaFoo) {
return new AlphaFoo();
} else if (userChoseAlphaBar) {
return new AlphaBar();
} // etc.
}

public Beta createBeta() {
if (userChoseBetaFoo) {
return new BetaFoo();
} else if (userChoseBetaBar) {
return new BetaBar();
} /*etc.*/
}
}
</pseudocode>

This works well if the user can independently choose which concrete
class for every implementation. However, if the user makes one choice, and
it affects ALL your interfaces as a set, you'll want to use the Abstract
Factory interface:

<pseudocode>
public interface Factory {
public Alpha createAlpha();
public Beta createBeta();
}

public class FooFactory implements Factory {
public Alpha createAlpha() {
return new AlphaFoo();
}

public Beta createBeta() {
return new BetaFoo()
}
}

public class BarFactory implements Factory {
public Alpha createAlpha() {
return new AlphaBar();
}

public Beta createBeta() {
return new BetaBar()
}
}

/*usage:*/

final Factory myFactory;
if (userChoseFoo) {
myFactory = new FooFactory();
} else if (userChoseBar) {
myFactory = new BarFactory();
}

Alpha a = factory.createAlpha();
Beta b = factory.createBeta();
</pseudocode>

With abstract factories, you can ensure your set "matches" (that is, if
you have a FOO variant of Alpha, then the Beta will also be a FOO variant,
and not a BAR variant).

- Oliver

 

[java-john]

Thanks All,

After reading your posts and doing more research, I found that the
problem I have has been addressed already. I keep seeing the following
keywords: service locator, inversion of control (IOC), and dependency
injection.

One of the frameworks that I see popping up to handle this type of
problem is Spring. However, I have read some posts cautioning against
"coding to avoid dependency on Spring" and I don't think something like
Spring may be appropriate for my relatively small-scale project.

 

[lewmania942]

After reading your posts and doing more research, I found that the

problem I have has been addressed already. I keep seeing the following
keywords: service locator, inversion of control (IOC), and dependency
injection.

Service locators and IoC containers are not the same as abstract
factories.

As other people already pointed out, what you probably want to
solve your problem is the pattern called "abstract factory".

You can also use, say, an IoC container in your project: at
some point in your program you tell the container "I want
an object implementing MyInterface" and it will give one to
you... According he has one (for example you explicitely
called a factory and registered the object in the IoC
container) or knows how to create one (for example you
registered some factory in a container "smart enough"
to automatically call factory methods).

So it's not "one or the other": using service locators/IoC containers
dont automagically render factories irrelevant.

 

[java-john]

lewmania,

I think you misunderstand my problem. I have an interface. I have
implemented the interface. However, at runtime (or somewhere
downstream), I want other users of the API to substitute one of their
implementation for mine. This is more in line with dependency injection
than abstract factories pattern.

Thanks.