Java – Instantiating a Class Implementing an Interface

java

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?

Best Answer

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.

Related Solutions

Java – Benefits of Using Static Inner Builder Class

I tend to follow a pattern that constructors should provide all of the mandatory values required to create a valid and consistent object. For optional values, I try to think about what the most common default should be, so that setters are used as little as possible.

If I find that there are lots of optional values or that a larger proportion of optional values tend to be altered from their defaults, then I'll use the builder pattern (static inner builder or other similar design).

Josh generally gives pretty darn good advice - the best thing I like about him is that the advice comes from the trenches - he admits himself that he made mistakes in designing parts of Java, and Effective Java is partly kind of his 'cure' so to speak :-)

Java – Using Super Keyword to Access Super Class Members

In addition to all the above, consider the following scenario:

You start out with these two classes.

 class A {
    int i = 20;

    A() {
        System.out.println("I am in constructor of the parent class");
    }
}

class B extends A {
    int i = 30;

    B() {
        System.out.println("I am in constructor of the subclass");
    }
}

You compile both classes, it creates two class files: A.class and B.class

Now you change your mind and rewrite A:

 class A {
    int i = 10;

    A() {
        System.out.println("I am in constructor of the parent class");
    }
}

You recompile A, so you get a new A.class, which you replace the old A.class with

Now the question is: how would B know that As initialisation code has changed? You haven't recompiled B, nor should you be required to do so. After all, B may already be packaged up in a different jar, maybe even in a different product you have no control over.*

The only reasonable way to support this case is for Bs constructor to start with calling As constructor and let A initialise itself.

*This may sound far-fetched at first, but this is exactly what happens when internal implementation details of JDK classes are changed. All the previously compiled Java applications in the world should run seamlessly with the new JDK.

Best Answer

Related Solutions

Java – Benefits of Using Static Inner Builder Class

Java – Using Super Keyword to Access Super Class Members

Related Topic