Co jest złego w nadpisywalnych wywołaniach metod w konstruktorach?

Oto przykład, który pomaga to zrozumieć:

public class Main {
    static abstract class A {
        abstract void foo();
        A() {
            System.out.println("Constructing A");
            foo();
        }
    }

    static class C extends A {
        C() { 
            System.out.println("Constructing C");
        }
        void foo() { 
            System.out.println("Using C"); 
        }
    }

    public static void main(String[] args) {
        C c = new C(); 
    }
}

Jeśli uruchomisz ten kod, otrzymasz następujące wyjście:

Constructing A
Using C
Constructing C

Wywołanie metody nadpisywalnej w konstruktorze pozwala podklasom obalić kod, więc nie możesz zagwarantować, że działa. Dlatego dostajesz Ostrzeżenie.

W twoim przykładzie, co się stanie, jeśli podklasa nadpisuje {[0] } i zwróci null ?

Aby to "naprawić", możesz użyć metody fabrycznej zamiast konstruktora, jest to powszechny wzorzec instancjacji obiektów.

Oto przykład, który ujawnia problemy logiczne , które mogą wystąpić podczas wywoływania nadpisywalnej metody w super konstruktorze.

class A {

    protected int minWeeklySalary;
    protected int maxWeeklySalary;

    protected static final int MIN = 1000;
    protected static final int MAX = 2000;

    public A() {
        setSalaryRange();
    }

    protected void setSalaryRange() {
        throw new RuntimeException("not implemented");
    }

    public void pr() {
        System.out.println("minWeeklySalary: " + minWeeklySalary);
        System.out.println("maxWeeklySalary: " + maxWeeklySalary);
    }
}

class B extends A {

    private int factor = 1;

    public B(int _factor) {
        this.factor = _factor;
    }

    @Override
    protected void setSalaryRange() {
        this.minWeeklySalary = MIN * this.factor;
        this.maxWeeklySalary = MAX * this.factor;
    }
}

public static void main(String[] args) {
    B b = new B(2);
    b.pr();
}

W rzeczywistości wynik będzie:

Minweeklysalary: 0

MaxWeeklySalary: 0

Jest to spowodowane tym, że konstruktor klasy B najpierw wywołuje konstruktor klasy A, gdzie metoda nadpisywalna wewnątrz B jest wykonywana. Ale wewnątrz metody używamy zmiennej instancji factor, która nie ma jeszcze została zainicjalizowana (ponieważ konstruktor a nie został jeszcze ukończony), więc współczynnik wynosi 0, a nie 1, a na pewno nie 2 (coś, co programista może myśleć, że będzie). Wyobraź sobie, jak trudno byłoby wyśledzić błąd, gdyby logika obliczeń była dziesięć razy bardziej pokręcona.

Jeśli wywołujesz metody w konstruktorze, które zastępują podklasy, oznacza to, że mniej prawdopodobne jest odwoływanie się do zmiennych, które jeszcze nie istnieją, jeśli logicznie podzielisz inicjalizację między konstruktor i metodę.

Spójrz na ten przykładowy link http://www.javapractices.com/topic/TopicAction.do?Id=215

W konkretnym przypadku Wicket: właśnie dlatego zapytałem Wicket Programiści dodający wsparcie dla jawnego dwufazowego procesu inicjalizacji komponentu w cyklu życia frameworka konstruowania komponentu, tj.

1. Budownictwo-przez konstruktora
2. Inicjalizacja-poprzez onInitilize (po budowie, gdy działają metody wirtualne!)

Była dość aktywna dyskusja na temat tego, czy jest to konieczne, czy nie (w pełni jest to konieczne IMHO) , ponieważ ten link demonstruje http://apache-wicket.1842946.n4.nabble.com/VOTE-WICKET-3218-Component-onInitialize-is-broken-for-Pages-td3341090i20.html)

Dobrą wiadomością jest to, że doskonali deweloperzy w Wicket nie skończyło się wprowadzenie dwufazowej inicjalizacji (aby najbardziej aweseome Java UI framework jeszcze bardziej niesamowite!) więc z Wicket możesz zrobić całą inicjalizację budowy post w metodzie onInitialize, która jest wywoływana przez framework automatycznie, jeśli ją nadpiszesz - w tym momencie w cyklu życia komponentu jego konstruktor zakończył pracę, więc metody wirtualne działają zgodnie z oczekiwaniami.

Myślę, że dla Wicket lepiej jest wywołać metodę add w onInitialize() (patrz components lifecycle) :

public abstract class BasicPage extends WebPage {

    public BasicPage() {
    }

    @Override
    public void onInitialize() {
        add(new Label("title", getTitle()));
    }

    protected abstract String getTitle();
}