Что не так с переопределенными вызовами методов в конструкторах?

При вызове переопределяемого метода из конструкторов

Проще говоря, это неверно, потому что это излишне открывает возможности для МНОЖЕСТВО ошибок. Когда вызывается @Override , состояние объекта может быть несовместимым и / или неполным.

Цитата из Эффективное 2-е издание Java, пункт 17: Дизайн и документация для наследования или запрета его :

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

Вот пример для иллюстрации:

public class ConstructorCallsOverride {
    public static void main(String[] args) {

        abstract class Base {
            Base() {
                overrideMe();
            }
            abstract void overrideMe(); 
        }

        class Child extends Base {

            final int x;

            Child(int x) {
                this.x = x;
            }

            @Override
            void overrideMe() {
                System.out.println(x);
            }
        }
        new Child(42); // prints "0"
    }
}

Здесь, когда конструктор Base вызывает overrideMe , Child не завершил инициализацию final int x , и метод получает неправильное значение. Это почти наверняка приведет к ошибкам и ошибкам.

Связанные вопросы

• Вызов переопределенного метода из конструктора родительского класса
• Состояние объекта производного класса, когда конструктор базового класса вызывает переопределенный метод в Java
• Использование абстрактной функции init () в конструкторе абстрактного класса

См. Также

• FindBugs - Неинициализированное чтение метода поля, вызываемого из конструктора суперкласса

При построении объекта с большим количеством параметров

Конструкторы с большим количеством параметров могут привести к плохой читаемости, и существуют лучшие альтернативы.

Вот цитата из Effective Java 2nd Edition, пункт 2: Рассмотрите шаблон построителя, когда сталкиваетесь со многими параметрами конструктора :

Традиционно программисты использовали шаблон телескопический конструктор , в котором вы предоставляете конструктор только с обязательными параметрами, другой - с одним необязательным параметром, третий - с двумя необязательными параметрами и так далее ...

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

public class Telescope {
    final String name;
    final int levels;
    final boolean isAdjustable;

    public Telescope(String name) {
        this(name, 5);
    }
    public Telescope(String name, int levels) {
        this(name, levels, false);
    }
    public Telescope(String name, int levels, boolean isAdjustable) {       
        this.name = name;
        this.levels = levels;
        this.isAdjustable = isAdjustable;
    }
}

И теперь вы можете выполнить любое из следующих действий:

new Telescope("X/1999");
new Telescope("X/1999", 13);
new Telescope("X/1999", 13, true);

Однако в настоящее время вы не можете установить только имя и ] isAdjustable и оставив уровней по умолчанию. Вы можете предоставить больше перегрузок конструктора, но, очевидно, число будет резко увеличиваться по мере увеличения количества параметров, и у вас может быть даже несколько аргументов boolean и int , что действительно приведет к беспорядку вещей.

Как видите, писать этот шаблон не очень приятно и еще менее приятно использовать (что здесь означает «истина»? Что такое 13?).

Блох рекомендует использовать шаблон компоновщика, который позволил бы вам вместо этого написать что-то вроде этого:

Telescope telly = new Telescope.Builder("X/1999").setAdjustable(true).build();

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

См. Также

• Википедия / шаблон построителя
• Эффективное второе издание Java, пункт 2: рассмотрите шаблон построителя, когда сталкиваетесь со многими параметрами конструктора ( отрывок в Интернете )

Соответствующий questions

• Когда вы бы использовали шаблон Builder?
• Это хорошо известный шаблон проектирования? Как его зовут?