How does Java Builder Heritage work?

Question

In Java when one class inherits from another it is necessary to initialize the constructor of the parent class, right? using the super() and passing to this super() the parameters the parent constructor asks for.

Parent class example:

public class Pessoa{
    protected String nome;
    protected String dataNasc;

    public Pessoa(String a, String b){
        nome = a;
        dataNasc = b;
    }
}

Here the builder asks for two strings, I want a class heiress of this to have a constructor that takes as parameters a String and a int, and so I initiate the super()?

This is the heiress class:

public class Cliente extends Pessoa{

    protected String endereco;
    protected static int codigoCliente;


    public Cliente(String a, int b){
        endereco = a;
        codigoCliente = b;
    }

}

Her builder asks for a String and a whole, doing this:

public Cliente(String a, int b){
    super(a, b);
    endereco = a;
    codigoCliente = b;
}

It is an error because I initialized with different types, my solution was this:

public Cliente(String a, Integer b){
    super(a, b.toString());
    endereco = a;
    codigoCliente = b;
}

There is another way to initialize an heir constructor that has different parameters than the parent constructor?

Answer 1

Don’t mix things up

You should not pass anything to the parent-class constructor. This is not so much to do with object orientation.

If the parent class gets a nome and a dataNasc then the daughter class needs to receive these values beyond what she herself already receives.

The correct implementation, both technically and in terms of values, would thus be:

public class Cliente extends Pessoa {

    protected String endereco;
    protected int codigoCliente;


    public Cliente(String a, String b, String c, int d) {
        super(a, b);
        endereco = c;
        codigoCliente = d;
    }

}

In short, your problem is not about the types, but what values are needed.

Think of daughter classes as an extension of parent class, so the attributes are cumulative.

Don’t mess with what you don’t understand

Remove the static of the attribute codigoCliente. This would cause the value to be shared across all instances of the class.

Avoid confusion

Use more descriptive parameter names than a or b. Maybe then you wouldn’t have been confused from the beginning.

For example:

public class Pessoa {
    protected String nome;
    protected String dataNasc;

    public Pessoa(String nome, String dataNasc){
        this.nome = nome;
        this.dataNasc = dataNasc;
    }
}

And the class Cliente:

public class Cliente extends Pessoa{

    protected String endereco;
    protected int codigoCliente;


    public Cliente(String nome, String dataNasc, String endereco, int codigoCliente) {
        super(nome, dataNasc);
        this.endereco = endereco;
        this.codigoCliente = codigoCliente;
    }

}

Answer 2

This makes no sense. The builder of Cliente is receiving, according to you, an address and a customer code. You are not receiving a name and date of birth. You cannot take an address and play in the name, even if they are of the same type, nor a code and play on the date of birth. The compiler may not complain if the types are compatible, but that doesn’t mean it’s right. He can’t know the semantics you want to give to the data.

So it is logical that it is impossible for you to initialize a complete class if you do not have all the data. There are some alternatives depending on what you want.

The most obvious is to ask for all necessary data in the class Cliente:

public Cliente(int codigo, String nome, String endereco, Date dataNasc){
    super(nome, dataNasc);
    this.endereco = endereco;
    codigoCliente = codigo;
}

Note that if the name of the class field matches that of the parameter I can disambiguate using the this to show that is the class instance field.

Note also that I preferred to receive the date of birth as a type Date, makes more sense. It’s obvious you need to change the type in the class Pessoa also.

I put more meaningful names in the parameters. Learn to program to make it easy to understand the code.

I changed the order of the parameters because it seems to make more sense.

But if you look deeper you will see that the organization of these classes makes even less sense. If it is a customer has a code but it is another type of person does not have? This is strange to me. The same goes for the address. Does every person have a date of birth?

Another change I would make is to call the field currently called codigoCliente only of codigo. If you’re in class Cliente, it is obvious that it is the client code. The name is redundant.

Nor does it make sense for a data that is clearly an instance field of the class to be declared as static. Static fields serve for unique class values throughout the application, they will not be present in each instance, in each object, will be only in the same class. It is a given shared by all objects in this class.

I didn’t even talk about encapsulation. This is a problem but it’s outside the scope of the question.

Another possibility is to leave some data unfilled if this is possible within what you expect.

public Cliente(int codigo, String nome){
    super(nome, null);
    codigoCliente = codigo;
}

I do not advise doing this but it is a possibility. In this way you left both the address worthless as the date of birth.

I would do so:

public class Pessoa {
    protected String nome;
    protected Date nascimento;

    public Pessoa(String nome, Date nascimento){
        this.nome = nome;
        this.nascimento = nascimento;
    }
}

public class Cliente extends Pessoa{
    protected String endereco;
    protected int codigo;

    public Cliente(int codigo String nome, String endereco, Date nascimento) {
        super(nome, nascimento);
        this.endereco = endereco;
        this.codigo = codigo;
    }
}

I put in the Github for future reference.

You don’t have to do it like this, but I think this shape is more elegant. Not yet perfect, I didn’t want to change anything fundamental to what you’re trying to do.