Перегрузка конструктора - лучшая практика в Java

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.

Обеспечение выполнения контракта достигается с помощью абстрактных методов или интерфейсов. Вы не можете быть уверены, что каждый подкласс будет иметь эти конструкторы, или, по крайней мере, вы не можете быть уверены, что каждый подкласс будет правильно добавлять эти конструкторы.

Итак, учитывая Инкапсуляция, эти конструкторы лучше подходят для суперкласса.

Что касается самого вопроса: я думаю, что оба варианта не идеальны.

Вы стремитесь писать как можно меньше кода. Вы осторожны при добавлении перегрузок только потому, что они кажутся удобный. На самом деле, вам следует сделать обратное: как следует подумать, какие у вас варианты использования настоящий, и поддерживать только их.

И в вашем случае весь смысл упражнения, похоже, состоит в том, чтобы разрешить сортировку с разными реализациями. И в этом смысле вам лучше посмотреть, например, на шаблон стратегии.

Другими словами: ваша мысль первый всегда предпочитать композицию наследованию. И когда ваш дизайн приводит вас к таким вопросам, ответ лучше может заключаться в том, чтобы отступить от вашего текущего дизайна и найти способ включить различную сортировку в качестве некой «службы» - вместо того, чтобы объединять сам список в единое целое для сортировки.

What is a better approach in case of consistency?

1. Сделайте все дочерние конструкторы закрытыми.

2. Представьте статические фабричные методы.

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

3. Выполните вызов подходящего конструктора super. Не проходите мимо null.

   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. Не используйте Optional как поле.

   this.original = Optional.ofNullable(li);

5. Рассмотрим Шаблон Строителя, если у вас 3+ параметра.

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

Конструктор должен предоставить начальные значения. Вы не передаете начальные значения, вы просто указание на их отсутствие.

По умолчанию null является начальным значением для ссылочных типов. Таким образом, нет необходимости переназначать поле, если для него не было задано значение.

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

Читаемость, обслуживание.

Я бы порекомендовал прочитать Эффективная Java от Джошуа Блоха:

Создание и уничтожение объектов

• Правило 1. Рассмотрите статические фабричные методы вместо конструкторов
• Правило 2: подумайте о строителе, когда сталкиваетесь со многими параметрами конструктора

Вы можете добавить последний addAll, который будет вызываться в дочерних конструкторах в качестве необязательного дополнения. Для компаратора семантика различается, он (почти) должен быть перегружен, когда это необязательно.

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);     
}

Лучше избегать нулевых параметров.

Если вы хотите, чтобы все подклассы имели одни и те же конструкторы, имея много конструкторов, это неплохо. Преимущество в том, что API для всех классов ведут себя одинаково. Однако это ненужный код котельной плиты, который может предотвратить шаблон строителя. В первоначальной старой java использовалось множество конструкторов, но в настоящее время можно встретить множество конструкторов в API.

Для сортировщика списков идеальной идеей может быть свободный API с использованием какого-либо конструктора.

Итак, окончательный ответ: решение в большей степени зависит от стиля.

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.

Подкласс не имеет ограничений для вызова определенного конструктора родительского класса. Он может вызывать любой из них, в то время как это вызывает один из них. Значит, вы не смогли добиться такого требования.

Что касается решения с использованием метода статической фабрики, в некоторых случаях это приемлемо и даже нормально, но это не чудо и также имеет некоторые ограничения. Например: не позволяет переходить на другие реализации. Я согласен с тем, что для классов JDK это почти никогда не проблема, но для пользовательского класса мы должны использовать его с осторожностью. Кроме того, ничто не мешает подклассу расширять родительский класс и не проходить мимо фабрики для создания экземпляров этого подкласса. Таким образом, указанное требование также не обеспечивается.

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?

Это не вопрос мнения. Это имеет значение. Если подкласс делегирует родительский класс и проверки всегда одинаковы, кажется интересным позволить родительскому классу выполнять проверки. Но если у вас нет гарантии, что родительский класс никогда не будет изменен в отношении проверок, подклассы могут создать некоторые экземпляры несогласованности, если родительский класс изменит свои проверки.