views:

171

answers:

8

I would like to know what purpose a constructor for an abstract class serves; as we do not instantiate abstract classes, why would we ever need such a constructor?

+4  A: 

They can still be invoked by constructors of classes that inherit from that one, making code refactoring a good use for having a constructor in the abstract class.

Miguel Ventura
+5  A: 

there will be times when you have some common initialization of instance variables that all the inheriting classes need to set up. You do instantiate an abstract class when you extend it and that concrete class has a constructor that will either supply the parameters to the constructor of the abstract class.

fuzzy lollipop
An example is javax.swing.AbstractAction
Steve Kuo
+3  A: 

If you have uninitialised final fields in an abstract class, you'll need to initialise them in a constructor.

E.g.

abstract class A {
    final int x;
}

will not compile without a constructor that assigns to x.

harto
+3  A: 

If your class doesn't declare a constructor, javac will make a no-arg, do-nothing constructor for you. Then, when your subclass is initialized, it will call the generated no-op constructor and life is good.

However, if your class declares any constructor, javac will NOT make one for you. In that case, the subclass constructor needs to explicitly call the constructor of the parent class. Otherwise, you'll fail to initialize members of the parent class, as the above answer mentions.

Kashif Q.
+1  A: 

Constructors for abstract classes are used by subclasses (invoked from subclass constructors using super(params) ).

You should make these constructors protected to make that clear.

Thilo
+2  A: 

You don't instantiate abstract classes but the constructor is invoked when a subclass is instantiated.

The use could be to initialize common attributes ie.

import java.util.List;
import java.util.ArrayList;
abstract class BaseClass {
    protected List list; // visible from subclasses

    public BaseClass() {
        System.out.println("to abstract...");
        // common initialization to all subclasses
        list = new ArrayList();
        list.add("a");
        list.add("a");
        list.add("a");
    }
}

class ConcreteClass extends BaseClass {
    public ConcreteClass(){
        // The list is initialized already
        System.out.println("now it is concrete and the list is: = "+ this.list );


    }
}

class TestAbstractClass {
    public static void main( String [] args ) {
        BaseClass instance = new ConcreteClass();
    }

}

Output

$ java TestAbstractClass
to abstract...
now it is concrete and the list is: = [a, a, a]
OscarRyz
+1  A: 

De-duplicating common knowledge/behaviour.

E.g. a Car: all your cars will be constructed out of a body and four wheels and an engine. So you do this part of the construction in the constructor for the abstract Car class by calling functions like Body(), Wheel(int x), Engine(). Each particular car class will have their own implementation of Body(), Wheel() and Engine() - but they all will do the same steps to construct the car from them, so there is no need to duplicate those steps in each of those classes. In this case you implement that common behaviour in the ancestor.

Bandi-T
A: 

I agree, Constructors are created assuming there will be instances. If you have lot of common code you can think of creating a Constructor but it is much better to put it in a init() method.

fastcodejava
this is bad advice, then every inheirting class needs to remember to call super.init() and it gets messy fast, this is non-standard and really bad advice.
fuzzy lollipop