Alternatives to using overridden methods in constructors, Java

Question

In a Java project I am coding I have ended up using methods that are overridden in constructors. Something like:

class SuperClass {
    SuperClass() {
        intialise();
    }

    protected void initialise() {
        //Do some stuff common to all subclasses
        methodA();
        methodB();
    }

    protected abstract void methodA();

    protected abstract void methodB();
}

class SubClass1() {
    SubClass() {
        super();
    }
    protected void methodA() { //Do something }
    protected void methodB() { //Do something }

}

class SubClass2() {
    SubClass() {
        super();
    }
    protected void methodA() { //Do something else }
    protected void methodB() { //Do something else}

}

I now realise, that although in my case it works fine, it is somewhat dangerous since SubClass methods are called on an object that has currently only been constructed as a SuperClass object (something that may be overlooked when new classes that extend SuperClass are added in the future). It also wouldn't work in c++ due to differences in how objects are created.

The only way I can think to get round this is to move the initialise method call down to the concrete classes constructor:

   class SuperClass {
    SuperClass() {            
    }

    protected void initialise() {
        methodA();
        methodB();
    }

    protected abstract void methodA();

    protected abstract void methodB();
}

class SubClass1() {
    SubClass() {
        super();
        initialise();
    }
    protected void methodA() { //Do something }
    protected void methodB() { //Do something }

}...

Is this the common way to over come this issue? It seems a shame (and easy to forget) that all further classes that extend SuperClass need to remember to call initialise().

I also found myself doing something similar in a more complicated situational that uses a Factory Method in a constructor, which is overridden in subclasses to decide which concrete class to implement. The only other way I can think to get round this and keep the design pattern as is, is to perhaps construct in a two phase process; ie construct with the bare minimum, and then call a second method to finish off the job.

Answer 1

Objects that need initialization as complex as this would really need to be created through factory methods. You do mention a factory, but being called from a constructor, so that doesn't sound like the straightforward approach, either. If you simply had a factory in the base class, publicly invisible constructors, and a mechanism to decide which concrete class to return, that factory would easily enforce the initialization policy.

Answer 2

This is really not a good idea as your Subclass will not be properly constructed when its methodA() and methodB() are called. That would be very confusing for people extending the class. Recommend you use an abstract init() instead, as suggested by dlev in his/her comment.

Answer 3

I wonder if you're making things more complicated than they need to be.

In your example, the stuff done by each implementation of methodA could be moved to the constructor of the class that does the implementation. So instead of using SubClass::methodA, just move the logic into the SubClass constructor.

If you do this you gain clarity at the expense of some potentially hard to understand control over the order the various initialization bits get executed.

Answer 4

Bruce Eckel在他的“Thinking in Java”中提出的建议是使你的methodA（）和类SuperClass的方法B（）最终或私有（隐式最终），因此它们可以从超类构造函数访问，尽管没有派生类会有访问这些方法，因此，不会有任何危险的覆盖 - 任何派生类中声明的类似签名的任何方法都只是新方法。