Instantiating a class implementing an interface

Question

I have an interface called Cell. In the start of the code, I read input data from which I can come to know the implementing class (not as a class object but I can know for example the string). And after that I need to call the constructor for the implementing class to initialize an object.

What would be the best way to implement that. The first thing in my mind is to do something like this (Cell is an interface, Sphere and Rectangle implements Cell. I can set a boolean flag called sphere after reading the input data):

Cell startcell;
if (sphere)
 startcell = new Sphere(0);
else
 startcell = new Rectangle(0);

But is this good design?

• yannis: @BalusC Well why not write an answer instead?
• Captain Jack sparrow: Thanks. So from the responses and wiki it looks to me that this way to instantiate is good enough.

Answer 1

Looks like Factory pattern, which is quite "endorsed" by design gurus, so to speak. See bottom of that Wikipedia pages for existing creation patterns for OOP languages, like Java.

• Victor Sorokin: Well, I'm not sure, but Wikipedia page I've linked shows Java snippets very similar to OP's (e.g., ImageReader example).
• yannis: quite "endorsed" by design gurus, so to speak is not a good enough reference for your answer. Who are these gurus? Can you provide sources that they endorse the Factory pattern for situations similar to the question? Can you provide any reference or reasoning for why you suggest the Factory pattern?
• pdr: @BalusC: See my answer to programmers.stackexchange.com/questions/81838/…. Victor is absolutely correct.

Answer 2

The if/else implementation is not very scalable - as soon as you add a Cube, you have to add another if condition. It's not really a design pattern, but Java can handle this with reflection. You can read the class name from some config and instantiate it and verify that it implements the appropriate interface. Just a side note, the Spring framework can do this for you too.

 // className is read from config, etc
 Class instantation = Class.forName(className);
 if (!Cell.class.isAssignableFrom(instantation))
 throw new Exception("Not a Cell!");
 Cell cell = (Cell) instantion.newInstance();

• Captain Jack sparrow: I have read that reflection should be used minimally. That isnt true?
• Victor Sorokin: Not always. I guess arguments there would go like 'reflection is slow and hard to maintain'. While this is generally true, in case like yours, reflection can pay off. Especially, if these objects you going to create are "high-level" objects and you don't need to create lot of them during runtime.
• pdr: How is if/else not scalable? It is easily converted to a switch/case, which is the exact point where you should be thinking about the factory method pattern (see Fowler, Refactoring).
• Victor Sorokin: I guess, jeff's point is the case when reflection allows to parameterize, e.g., via property, which type to instantiate, without recompilation of factory code.
• kevin cline: Reflection breaks refactoring.