Is it correct to create a constructor method in an abstract class?

Question

If an abstract class cannot be instantiated, can creating a constructor method for this abstract class be regarded as good practice or not? If so, why are we creating the implementation of this method?

Below is an excerpt of code that illustrates my question:

public abstract class Funcionario {

    private String nome;
    private int numeroRegistro;

    public Funcionario(int numeroRegistro) {
        setNumeroRegistro(numeroRegistro);
    }

    public String getNome() {
        return nome;
    }

    public void setNome(String nome) {
        this.nome = nome;
    }

    public int getNumeroRegistro() {
        return numeroRegistro;
    }

    public void setNumeroRegistro(int numeroRegistro) {
        this.numeroRegistro = numeroRegistro;
    }

    public abstract double obterSalarioBruto();

    @Override
    public String toString() {
        return "Funcionario [getNome()=" + getNome() + ", getNumeroRegistro()=" + getNumeroRegistro() + "]";
    }

}

Answer 1

It’s correct, of course. Unless the builder is not necessary. And it isn’t always. Many programmers create constructor without need. Others stop creating when "it’s required" to have.

But if the abstract class has states (usually has) and they need to be initialized when an object based on it (not by direct instantiation, of course, but because another class inherited from it) is created, then the constructor needs to be called, though indirectly through the daughter class.

Has a question about the call of the constructor of a higher class by a lower class. It makes no difference whether the class is abstract or not.

Obviously, if the class has no state, i.e., internal variables, it is unlikely that a constructor is necessary. But there is another problem, also not exclusive of abstract classes. And if the class has not been, it probably should be static.

Avoid calling other methods within the constructor. Normally it should initialize the variables directly. Depending on the called method it can be dangerous and put the instance in doubtful state or break the application. It does not mean that it is wrong to call the methods, just make sure it is what you want, often the logic of initialization is different from the logic of attribution. This case is the same thing, so it seems appropriate to use the same. But this is an opposite case to DRY. Now the code does the same, then there is a maintenance and they go on to do different things. The code starts to have problems because it was conceptually poorly conceived (of course you can fix it together, but you can forget you have to). Note that I am in the field of hypothesis, the concrete case should always be evaluated.