Dlaczego konstruktor jest wywoływany w odwrotnej kolejności?

Question

W dziedziczeniu dlaczego konstruktor klasy podstawowej najpierw otrzymuje wywołanie, dlaczego nie pochodzi?

Answer 1

Aby upewnić się, że publiczni lub chronieni członkowie klasy bazowej są poprawnie zainicjowani, zanim zostaną zastosowani w klasie pochodnej.
Precyzyjnie, konstruktor klasy pochodnej jest uruchamiany jako pierwszy z niejawnym wywołaniem do konstruktora klasy podstawowej wstawionego jako pierwsza instrukcja w treści konstruktora klasy pochodnej przez kompilator (przyjmując domyślne konstruktory bez-arg).

Answer 2

Klasa pochodna jest tworzona przez rozszerzenie klasy bazowej. Należy upewnić się, że członkowie klasy podstawowej są poprawnie zainicjowani, zanim będzie można ich rozszerzyć w klasie pochodnej. Ponadto członkowie inicjowani w klasie pochodnej nie powinni być nadpisywani przez klasę podstawową.

Answer 3

Co rodzi się pierwszy, rodzic lub dziecko?

Answer 4

Zastanów się, co mogłoby się stać, gdyby było odwrotnie. Wyobraźmy sobie klasę użytkownika o wartości _id. _id z 0 jest specjalnymi wartościami, które reprezentują konto "gościa" (zignoruj ​​problemy wokół "wartości specjalnych", po pierwsze nie zawsze są złym pomysłem, a po drugie jest to tylko przykład). _id również nie może zostać zmieniony po zbudowaniu (co ma sens, jeśli można go zmienić nie jest już tak naprawdę identyfikatorem).

public class User 
{ 
    private readonly int _id; 
    public User(int id) 
    { 
    _id = id; 
    } 
    public int ID 
    { 
    get { return _id; } 
    } 
    public bool IsGuest 
    { 
    get { return _id == 0; } 
    } 
} 

Teraz należy rozważyć klasę Admin, która podklasuje od tego. Jedną z zasad klasy Admin jest to, że gość nigdy nie może być administratorem. Ta niezmienna powinny być egzekwowane we wszystkich punktach status gość może się zmienić, co w tym przypadku jest tylko w konstruktorze:

public class Admin : User 
{ 
    public Admin(int id) 
    :base(id) 
    { 
    if(IsGuest) 
     throw new SecurityException("Guest users cannot be admins."); 
    } 
} 

Jeśli Admin został zbudowany przed User wtedy zawsze rzucić ten wyjątek, gdyż badanie zawsze porównaj 0 z 0. Gdybyśmy mieli inną specjalną wartość dla gości, to byłoby jeszcze gorzej i nigdy nie wyrzucajmy wyjątku nawet wtedy, gdy powinien, i pozwól na problem z bezpieczeństwem.

Należy pamiętać, że osoba pisząca klasę Admin nie musi mieć żadnej wiedzy o tym, jak działa User poza tym, co jest udokumentowane na temat jego publicznego i chronionego interfejsu. Mogą oni uchwycić powyższy problem, dodając własny test na to, czy id ma wartość zero, czy nie, ale oprócz tego, że jest to niepotrzebne powielanie kodu, nie ma powodu, dla którego powinni wiedzieć, w jaki sposób działa sprawdzanie IsGuest i może być o wiele bardziej skomplikowane. niż jest powyżej, a może być zastrzeżonym, zaciemnionym i nieudokumentowanym.

Bardziej ogólna koncepcja "konstruowania administratora" nie ma sensu bez koncepcji "konstruowania użytkownika" jako czegoś, co wydarzyło się jako pierwsze, nie możemy stworzyć bardziej wyspecjalizowanego typu X bez tworzenia X jako warunek wstępny.