Dlaczego używanie „finału” na zajęciach jest tak złe?

Refaktoryzuję starszą stronę PHP OOP.

Kusi mnie, aby zacząć używać „końcowego” na zajęciach do „ make it explicit that the class is currently not extended by anything”. Może to zaoszczędzić dużo czasu, jeśli przyjdę na zajęcia i zastanawiam się, czy mogę zmienić nazwę / usunąć / zmodyfikować protectedwłaściwość lub metodę. Jeśli naprawdę chcę rozszerzyć klasę, mogę po prostu usunąć ostatnie słowo kluczowe, aby odblokować je do rozszerzenia.

To znaczy, jeśli przyjdę na zajęcia, na których nie ma zajęć dla dzieci, mogę zapisać tę wiedzę, zaznaczając klasę na końcu. Następnym razem, gdy do niego dojdę, nie będę musiał ponownie przeszukiwać bazy kodu, aby sprawdzić, czy ma ona dzieci. W ten sposób oszczędzasz czas podczas refaktoryzacji.

To wszystko wydaje się rozsądnym pomysłem na oszczędzanie czasu ... ale często czytałem, że zajęcia należy kończyć tylko na rzadkie / specjalne okazje.

Może to psuje tworzenie fałszywych obiektów lub ma inne skutki uboczne, o których nie myślę.

czego mi brakuje?

Często czytałem, że zajęcia powinny być „ostateczne” tylko w rzadkich / specjalnych przypadkach.

Ktokolwiek to napisał, jest zły. Używaj finalswobodnie, nie ma w tym nic złego. Dokumentuje, że klasa nie została zaprojektowana z myślą o dziedziczeniu, i jest to zwykle prawdą domyślnie dla wszystkich klas: projektowanie klasy, którą można w sposób znaczący odziedziczyć, wymaga więcej niż tylko usunięcia finalspecyfikatora; wymaga dużo uwagi.

Dlatego używanie finaldomyślnie nie jest złe. W rzeczywistości wiele osób uważa, że ​​powinno to być domyślne, np. Jon Skeet .

Może to psuje tworzenie fałszywego obiektu…

Jest to rzeczywiście zastrzeżenie, ale zawsze możesz skorzystać z interfejsów, jeśli chcesz wyśmiewać swoje klasy. Jest to z pewnością lepsze niż udostępnienie wszystkich klas dziedziczeniu tylko w celu kpienia.

Jeśli chcesz zostawić sobie notatkę, że klasa nie ma podklas, to zrób to i użyj komentarza, po to jest. „Ostateczne” słowo kluczowe nie jest komentarzem, a używanie słów kluczowych w języku tylko w celu zasygnalizowania czegoś (i tylko Ty będziesz wiedział, co to znaczy), jest złym pomysłem.

Jest ładny artykuł na temat „Kiedy ogłaszać klasę jako ostateczną” . Kilka cytatów z tego:

TL; DR: Twórz klasy zawsze final, jeśli implementują interfejs i nie są zdefiniowane żadne inne metody publiczne

Dlaczego muszę używać final?

1. Zapobieganie masowemu spadkowi łańcucha losu
2. Zachęcająca kompozycja
3. Zmuś programistę do myślenia o publicznym interfejsie API użytkownika
4. Zmuś programistę do zmniejszenia publicznego interfejsu API obiektu
5. finalKlasa może być zawsze rozciągliwa
6. extends przerywa enkapsulację
7. Nie potrzebujesz tej elastyczności
8. Możesz zmienić kod

Kiedy unikać final:

Klasy końcowe działają skutecznie tylko przy następujących założeniach:

1. Istnieje abstrakcja (interfejs), którą implementuje ostatnia klasa
2. Cały publiczny interfejs API ostatecznej klasy jest częścią tego interfejsu

Jeśli brakuje jednego z tych dwóch warunków wstępnych, prawdopodobnie osiągniesz moment, w którym sprawisz, że klasa będzie rozszerzalna, ponieważ twój kod tak naprawdę nie opiera się na abstrakcjach.

PS Dzięki @ocramius za wspaniałą lekturę!

„końcowy” dla klasy oznacza: Chcesz podklasę? Śmiało, usuń „ostateczną” podklasę, ile chcesz, ale nie narzekaj, jeśli to nie działa. Jesteś sam.

Gdy klasę można zaklasyfikować do podklasy, jej zachowanie, na którym polegają inni, należy opisać abstrakcyjnie, zgodnie z podklasami. Dzwoniący muszą być napisani, aby oczekiwać pewnej zmienności. Dokumentacja musi być starannie napisana; nie możesz powiedzieć ludziom, żeby „patrzyli na kod źródłowy”, ponieważ kodu źródłowego jeszcze nie ma. To wszystko wysiłek. Jeśli nie oczekuję, że klasa jest podklasowana, to jest to niepotrzebny wysiłek. „końcowy” wyraźnie mówi, że wysiłek ten nie został podjęty i daje uczciwe ostrzeżenie.

Jedną z rzeczy, o których być może nie pomyślałeś, jest fakt, że DOWOLNA zmiana klasy oznacza, że ​​musi ona przejść nowe testy jakości.

Nie oznaczaj rzeczy jako ostatecznych, chyba że naprawdę, naprawdę masz na myśli.

Użycie „ostatecznego” zabiera swobodę innym, którzy chcą korzystać z twojego kodu.

Jeśli kod, który piszesz, jest tylko dla ciebie i nigdy nie zostanie udostępniony publicznie ani klientowi, możesz oczywiście zrobić z tym kodem, co chcesz. W przeciwnym razie uniemożliwisz innym korzystanie z Twojego kodu. Zbyt często musiałem pracować z interfejsem API, który byłby łatwy do rozszerzenia dla moich potrzeb, ale wtedy przeszkadzało mi „końcowe”.

Ponadto często istnieje kod, którego lepiej nie tworzyć private, ale protected. Jasne, privateoznacza „enkapsulację” i ukrywanie rzeczy uważanych za szczegóły implementacji. Ale jako programista API równie dobrze mogę udokumentować fakt, że metoda xyzjest uważana za szczegół implementacji, a zatem może zostać zmieniona / usunięta w przyszłej wersji. Tak więc każdy, kto pomimo ostrzeżenia będzie polegał na takim kodzie, robi to na własne ryzyko. Ale może to zrobić i ponownie wykorzystać (mam nadzieję, że już przetestowany) kod i szybciej znaleźć rozwiązanie.

Oczywiście, jeśli implementacja API jest open source, można po prostu usunąć „końcowy” lub uczynić metody „chronionymi”, ale następnie zmieniłeś kod i musisz śledzić zmiany w postaci łatek.

Jeśli jednak implementacja jest zamkniętym źródłem, nie możesz znaleźć obejścia lub, w najgorszym przypadku, przejść na inny interfejs API z mniejszymi ograniczeniami dotyczącymi możliwości dostosowywania / rozszerzenia.

Zauważ, że nie uważam, że „ostateczny” lub „prywatny” jest zły, ale myślę, że są po prostu zbyt często używane, ponieważ programista nie pomyślał o swoim kodzie pod względem ponownego użycia i rozszerzenia kodu.