Constructor overloading - best practice in Java

Question

Constructors can be overloaded as any other method as well and I am aware of that fact. Due to a task I decided to use an abstract superclass with multiple constructors:

Abstract Superclass:

protected ListSortierer()
{
  this( null, null );
}

protected ListSortierer( List<E> li )
{
  this( li, null );
}

protected ListSortierer( Comparator<E> comp )
{
  this( null, comp );     
}

protected ListSortierer( List<E> li, Comparator<E> com )
{
  this.original = Optional.ofNullable( li );
  this.comp = Optional.ofNullable( com );
}

To access each of these constructors I needed multiple constructors in the subclass as well.

BubbleSort.java:

public ListBubbleSort()
{
  super();
}

public ListBubbleSort( List<E> li )
{
  super( li );
}

public ListBubbleSort( Comparator<E> com )
{
  super( com );
}

public ListBubbleSort( List<E> li, Comparator<E> com )
{
  super( li, com );
}

In this case every constructor of the subclass calls the constructor of the superclass immediately.It came to my mind that I could refer to the own constructor again and pass null values:

public ListBubbleSort()
{
  this( null, null );
}

public ListBubbleSort( List<E> li )
{
   this( li, null );
}

public ListBubbleSort( Comparator<E> com )
{
   this( null, com );
}

public ListBubbleSort( List<E> li, Comparator<E> com )
{
   super( li, com );
}

Doing so would allow me to omit 3 of the overloaded constructors in the abstract superclass but would enforce that every subclass follows the same pattern.

My question is: What is the the better approach in case of consistency?Handle missing values in the abstract superclass or in the subclass? Does it make a difference regarding instantiation or is it just a matter of opinion?

Answer 1

What is a better approach in case of consistency?

1. Make all child constructors private.

2. Introduce static factory methods.

   ListBubbleSort.withList(List<E> list)
   ListBubbleSort.withComparator(Comparator<E> comparator)
   

3. Make a call to a proper super constructor. Don't pass any nulls.

   public static <E> ListBubbleSort withList(List<E> list) {
       return new ListBubbleSort(list);
   }
   
   private ListBubbleSort(List<E>) {
       super(list);
   }
   
   protected ListSortierer(List<E>) {
       // initialise only the list field
       this.origin = list;
   }
   

4. Don't use Optional as a field.

   this.original = Optional.ofNullable(li);

5. Consider the Builder Pattern if you have 3+ parameters.

Handle missing values in the abstract superclass or in the subclass?

A constructor is supposed to provide initial values. You aren't passing initial values, you are just indicating their absence.

By default, null is the initial value for reference types. So, there is no need to reassign a field if the value for it hasn't been given.

Does it make a difference regarding instantiation or is it just a matter of opinion?

Readability, maintenance.

---

I would recommend reading Effective Java by Joshua Bloch:

Creating and Destroying Objects

• Item 1: Consider static factory methods instead of constructors
• Item 2: Consider a builder when faced with many constructor parameters

Answer 2

Regarding the question itself: I think that both options aren't ideal.

You strive to write as few code as possible. You are careful about adding overloads just because they seem convenient. Actually, you should do the reverse: think very hard what your your real use cases are, and only support those.

And in your case, the whole point of the exercise seems to be to allow sorting with different implementations. And in that sense, you should rather look into the strategy pattern for example.

In other words: your first thought is always prefer composition over inheritance. And when your design leads you to such questions, the better answer might be to step back from your current design and find a way to enable different sorting as some sort of "service" - instead of backing the list itself together into a sorting thing.

Answer 3

Doing so would allow me to omit 3 of the overloaded constructors in the abstract superclass but would enforce that every subclass follows the same pattern.

Enforcing a contract is achieved via abstract methods or interfaces. You cannot be sure that every subclass will have these constructors, or at least you cannot be sure that every subclass will add these constructors properly.

So, considering Encapsulation, these constructors are better off in the superclass.

Answer 4

Doing so would allow me to omit 3 of the overloaded constructors in the abstract superclass but would enforce that every subclass follows the same pattern.

A subclass doesn't have any constraint to invoke a specific constructor of the parent class. It may invoke any of them while this invoke one of them.
So you could not achieve such a requirement.

About the solution using a static factory method, in some cases it is acceptable and even fine but that it not miracle and has also some limitations.
For example : it doesn't allow to switch to another implementations.
For JDK classes, I agree that it is almost never an issue but for custom class we should use it with cautious.
Besides, nothing prevents a subclass from extending the parent class and to not pass by a factory to create instances of this subclass.
So the quoted requirement is not ensured either.

My question is: What is the the better approach in case of consistency?Handle missing values in the abstract superclass or in the subclass? Does it make a difference regarding instantiation or is it just a matter of opinion?

It is not a question of opinion. It matters.
If the subclass delegates to the parent class and that the checks are always the same, it seems interesting to let the parent class to perform the checks.
But if you don't have guarantee that the parent class be never modified about the checks, the subclasses may create some inconsistency instances if the parent class changes its checks.

Answer 5

You can add a final addAll, to be called in the child constructors as optional extra. For the comparator the semantics differ, it (almost) must be overloaded when optional.

private final Optional<Comparator<E>> comparatorOption;

public final void addAll(List<E> li) {
    ...;
}

protected ListSortierer() {
    comparatorOption = Optional.empty();     
}

protected ListSortierer(Comparator<E> comp) {
    comparatorOption = Optional.of(comp);     
}

Avoiding null parameters seems better.

Prescribing all subclasses to have the same constructors by having many constructors is not bad if you want to. The advantage is that the API for all classes behave the same. It is however unnecessary boiler plate code, that a builder pattern could prevent. In the original old java many constructors were the way to go, but nowadays one sees many builders in APIs.

For a list sorter a fluent API using some kind of builder might be an idea.

So the final answer: more a contextual style decision.