Konstruktor zasadniczo nie powinien wywoływać metod

Opisałem koledze, dlaczego konstruktor wywołujący metodę może być antypatternem.

przykład (w moim zardzewiałym C ++)

class C {
public :
    C(int foo);
    void setFoo(int foo);
private:
    int foo;
}

C::C(int foo) {
    setFoo(foo);
}

void C::setFoo(int foo) {
    this->foo = foo
}

Chciałbym motywować ten fakt lepiej poprzez wasz dodatkowy wkład. Jeśli masz przykłady, odniesienia do książek, strony na blogu lub nazwy zasad, będą one bardzo mile widziane.

Edycja: Mówię ogólnie, ale kodujemy w Pythonie.

Nie określiłeś języka.

W C ++ konstruktor musi uważać podczas wywoływania funkcji wirtualnej, ponieważ rzeczywista funkcja, którą wywołuje, jest implementacją klasy. Jeśli jest to czysto wirtualna metoda bez implementacji, będzie to naruszenie zasad dostępu.

Konstruktor może wywoływać funkcje inne niż wirtualne.

Jeśli Twoim językiem jest Java, w którym funkcje są domyślnie wirtualne, warto zachować szczególną ostrożność.

Wydaje się, że C # radzi sobie z sytuacją tak, jak byś się spodziewał: możesz wywoływać metody wirtualne w konstruktorach i wywołuje najbardziej ostateczną wersję. Więc w C # nie jest anty-wzorem.

Częstym powodem wywoływania metod z konstruktorów jest to, że masz wielu konstruktorów, którzy chcą wywołać wspólną metodę „init”.

Zauważ, że destruktory będą miały ten sam problem z metodami wirtualnymi, dlatego nie możesz mieć wirtualnej metody „czyszczenia”, która znajduje się poza twoim destruktorem i oczekujesz, że zostanie wywołany przez destruktor klasy podstawowej.

Java i C # nie mają destruktorów, mają finalizatory. Nie znam zachowania w Javie.

Wygląda na to, że C # poprawnie obsługuje czyszczenie.

(Zauważ, że chociaż Java i C # mają funkcje odśmiecania pamięci, to tylko zarządza alokacją pamięci. Istnieje jeszcze inne czyszczenie, które musi wykonać Twój destruktor, ale nie zwalnia ono pamięci).

OK, teraz, że zamieszanie dotyczące metod klasy vs metody instancji jest wyjaśniona, mogę dać odpowiedź :-)

Problem nie polega na wywołaniu metod instancji w ogóle z konstruktora; dotyczy to wywoływania metod wirtualnych (bezpośrednio lub pośrednio). A głównym powodem jest to, że obiekt wewnątrz konstruktora nie jest jeszcze w pełni zbudowany . A zwłaszcza jego części podklasy wcale nie są konstruowane podczas działania konstruktora klasy podstawowej. Zatem jego stan wewnętrzny jest niespójny w sposób zależny od języka, co może powodować różne subtelne błędy w różnych językach.

C ++ i C # zostały już omówione przez innych. W Javie zostanie wywołana metoda wirtualna najbardziej pochodnego typu, jednak ten typ nie został jeszcze zainicjowany. Jeśli więc w tej metodzie są używane pola z typu pochodnego, pola te mogą jeszcze nie zostać poprawnie zainicjowane w tym momencie. Problem ten został szczegółowo omówiony w punkcie 17 wydajnej wersji Java 2. edycji : Projekt i dokument do dziedziczenia, w przeciwnym razie jest to zabronione .

Należy zauważyć, że jest to szczególny przypadek ogólnego problemu przedwczesnego publikowania odwołań do obiektów . Metody instancji mają thisparametr niejawny , ale thisjawne przekazanie do metody może powodować podobne problemy. Zwłaszcza w programach współbieżnych, w których jeśli odwołanie do obiektu jest przedwcześnie publikowane w innym wątku, wątek ten może już wywoływać metody przed zakończeniem konstruktora w pierwszym wątku.

Nie uważałbym, że wywołania metod tutaj są antypatternem, a raczej zapachem kodu. Jeśli klasa dostarcza resetmetodę, która przywraca obiekt do pierwotnego stanu, wówczas wywoływanie reset()konstruktora to DRY. (Nie wypowiadam się na temat metod resetowania).

Oto artykuł, który może pomóc w spełnieniu twojego apelu o autorytet: http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/

Tak naprawdę nie chodzi o wywoływanie metod, ale o konstruktory, które robią za dużo. IMHO, wywoływanie metod w konstruktorze to zapach, który może wskazywać, że konstruktor jest zbyt ciężki.

Jest to związane z tym, jak łatwo przetestować kod. Powody obejmują:

1. Testy jednostkowe obejmują wiele kreacji i zniszczeń - dlatego budowa powinna być szybka.

2. W zależności od tego, co robią te metody, może to utrudnić testowanie dyskretnych jednostek kodu bez polegania na pewnych (potencjalnie niemożliwych do przetestowania) warunkach wstępnych ustawionych w konstruktorze (np. Uzyskaniu informacji z sieci).

Filozoficznie, celem konstruktora jest przekształcenie surowej części pamięci w instancję. Podczas wykonywania konstruktora obiekt jeszcze nie istnieje, dlatego wywoływanie jego metod jest złym pomysłem. W końcu możesz nie wiedzieć, co robią wewnętrznie, i mogą słusznie uznać, że obiekt przynajmniej istnieje (duh!), Kiedy zostaną wywołani.

Technicznie rzecz biorąc, nie może być w tym nic złego, w C ++, a zwłaszcza w Pythonie, od ciebie zależy, abyś był ostrożny.

Praktycznie powinieneś ograniczać wywołania tylko do takich metod, które inicjują członków klasy.

To nie jest problem ogólnego zastosowania. Jest to problem w C ++, szczególnie podczas korzystania z dziedziczenia i metod wirtualnych, ponieważ konstrukcja obiektu odbywa się wstecz, a wskaźniki vtable są resetowane z każdą warstwą konstruktora w hierarchii dziedziczenia, więc jeśli wywołujesz metodę wirtualną, możesz nie w końcu dostajesz taki, który faktycznie odpowiada klasie, którą próbujesz stworzyć, co pokonuje cały cel korzystania z metod wirtualnych.

W językach z rozsądną obsługą OOP, które od samego początku ustawiają wskaźnik vtable, ten problem nie istnieje.

Istnieją dwa problemy z wywoływaniem metody:

• wywoływanie metody wirtualnej, która może albo zrobić coś nieoczekiwanego (C ++), albo użyć części obiektów, które nie zostały jeszcze zainicjowane
• wywołanie metody publicznej (która powinna wymusić niezmienniki klasy), ponieważ obiekt niekoniecznie jest jeszcze kompletny (a zatem jego niezmiennik może się nie utrzymywać)

Nie ma nic złego w wywoływaniu funkcji pomocnika, o ile nie mieści się ona w dwóch poprzednich przypadkach.

Nie kupuję tego. W systemie obiektowym wywołanie metody jest właściwie jedyną rzeczą, którą możesz zrobić. W rzeczywistości jest to mniej więcej definicja „obiektowa”. Jeśli więc konstruktor nie może wywołać żadnej metody, to co może zrobić?

W teorii OOP nie powinno to mieć znaczenia, ale w praktyce każdy język programowania OOP obsługuje konstruktory inaczej . Nie używam często metod statycznych.

W C ++ i Delphi, gdybym musiał podać wartości początkowe niektórym właściwościom („elementom pola”), a kod jest bardzo rozszerzony, dodaję dodatkowe metody jako rozszerzenie konstruktorów.

I nie nazywaj innych metod, które robią bardziej złożone rzeczy.

Jeśli chodzi o metody „getters” i „setters”, zwykle używam zmiennych prywatnych / chronionych do przechowywania ich stanu, a także metod „getters” i „setters”.

W konstruktorze przypisuję „domyślne” wartości do pól stanu właściwości, BEZ wywoływania „akcesorów”.