Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How to decide at runtime which concrete class implementation to instantiate

Reply
Thread Tools

How to decide at runtime which concrete class implementation to instantiate

 
 
java-john
Guest
Posts: n/a
 
      03-07-2006
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();
}
}

 
Reply With Quote
 
 
 
 
Ed Kirwan
Guest
Posts: n/a
 
      03-07-2006
java-john wrote:
> 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();
}
}

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
http://www.EdmundKirwan.com/servlet/...c-page130.html
 
Reply With Quote
 
 
 
 
vikasvirgo169@yahoo.com
Guest
Posts: n/a
 
      03-07-2006

java-john wrote:

> 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

 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      03-07-2006
On 7 Mar 2006 07:10:19 -0800, "java-john" <java->
wrote, quoted or indirectly quoted someone who said :

>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
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      03-07-2006

"java-john" <java-> wrote in message
news: oups.com...
>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

 
Reply With Quote
 
java-john
Guest
Posts: n/a
 
      03-07-2006
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.

 
Reply With Quote
 
lewmania942@yahoo.fr
Guest
Posts: n/a
 
      03-07-2006
> 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.

 
Reply With Quote
 
java-john
Guest
Posts: n/a
 
      03-08-2006
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Template class and class design on concrete example xl2csv writer Karim Python 0 11-23-2011 06:04 PM
Why RMI Stub depends On Concrete Remote Class? narke Java 11 04-22-2005 07:45 AM
Abstract class derived from concrete class? Wat C++ 2 12-04-2004 09:04 PM
[Reflection] Possible to query instance of abstract top level classwithout having the .class file of the concrete class? Stefan Siegl Java 1 08-19-2004 02:26 AM
Concrete class mead C++ 9 05-04-2004 03:29 AM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57