Use of 'super' in constructors

[Mohammed Azeem]

Good Evening,

I've been playing around constructors and inheritance.

I know that constructors are not inherited but those of a base class can be referred to by 'super'.

So what happens when, the derived class has no user-defined constructor but the base class does ?

In the following code:
  *   class A extends B.
  *   A is given a user-defined constructor; B is not.  So the compile ought to provide it with the construtor:
       

 B() {  } 

equivalent to:
       

 B() { super(); }

  *  The code fails unless line 21 is uncommented

All insights greatly appreciated,

Mohammed.

package ReviseSuperInConstructors;

/**
 *
 * @author MA
 */
public class ReviseSuperInConstructors {

    public static void main(String[] args) {
       
        B objb = new B();
        System.out.println("stringa in objb = " + objb.stringa);
        System.out.println("stringb in obj = " + objb.stringb);
        
    }  
}

class A {
    String stringa;
    
    // public A() {}
    
    public A(String stringa) {
        this.stringa = stringa; 
    }
    public void methodA() {
        System.out.println("Method A in Class A");
    }
}

class B extends A {
    String stringb = "String in Class B";
    
}

[Campbell Ritchie]

Mohammed Azeem wrote:Good Evening, . . .

Good evening . . .

I know that constructors are not inherited but those of a base class can be referred to by 'super'. .  . .
  *   class A extends B.
  *   A is given a user-defined constructor; B is not.  So the compile ought to provide it with the construtor:
       

 B() {  } 

equivalent to:
       

 B() { super(); }

. . .

Yes, you are correct. If you call javap −c B you can inspect the bytecode and see that you do indeed have such a constructor, only it will be named <init>. Remember you only get bytecode after the souirce code has been compiled. The subclass constructor calls super(); first before doing anything else. That means your superclass has to have a non‑private constructor taking no arguments. The code will only compile if you have a no‑arguments constructor in the superclass. The example you showed only has a constructor with a String parameter in class A, so the javac tools cannot find a no‑arguments constructor, and it will not compile class B. If you uncomment the no‑arguments constructor in line 21, the code will compile, but will not run correctly because the field in the A object will always point to null, which you probably don't want.

[Mohammed Azeem]

OK, thanks Campbell.

I extend classes willy-nilly.

So is it good practice to provide a no-parameter constructor in my own classes in case I or others wish to extend it, or is it up to users to look at the documentation to see which constructors are available ?

[Paul Clapham]

Mohammed Azeem wrote:So is it good practice to provide a no-parameter constructor in my own classes in case I or others wish to extend it, or is it up to users to look at the documentation to see which constructors are available ?

If it isn't necessary for your class to have a no-parameter class, then don't give it one. Of course people who are extending a class should look at the documentation for that class.

[Campbell Ritchie]

Mohammed Azeem wrote:OK, thanks Campbell.

That's a pleasure

I extend classes willy-nilly.

Twenty years ago it was taught that subclasses/inheritance were an essential part of object‑orientation, but now people realise that too much inheritance can cause problems. Make sure all inheritance follows the Liskov Substitution Principle and that all subclasses have a bona fide IS‑A relationship with their superclasses.

So is it good practice to provide a no-parameter constructor in my own classes in case I or others wish to extend it, . . .

Paul has already told you to avoid unnecessary constructors. I agree with him.