Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Często zdarza się, że osoby uczące się programowania mylą dziedziczenie z innymi pojęciami, takimi jak asynchroniczność czy zarządzanie stałymi. Zacznijmy od tego, że asynchroniczna realizacja długotrwałych zadań to zupełnie inny temat – tutaj chodzi o wielowątkowość, operacje asynchroniczne czy użycie mechanizmów typu async/await, które pozwalają na nieblokujące wykonywanie operacji, np. zapytania do bazy czy pobieranie plików z sieci. Dziedziczenie nie ma z tym absolutnie nic wspólnego. Jeżeli chodzi o stałe wartości, to są one definiowane zazwyczaj przy pomocy słów kluczowych takich jak "const" czy "final" albo przez odpowiednią konfigurację, a nie przez dziedziczenie. To raczej kwestia zarządzania niezmiennymi danymi w klasach, nie ich rozszerzania. No i jeszcze kwestia zasięgu dostępności metod oraz pól – tutaj w grę wchodzą modyfikatory dostępu, takie jak public, private czy protected. To one decydują, co jest widoczne na zewnątrz klasy, a nie sam mechanizm dziedziczenia. W sumie, często widzę, że osoby początkujące próbują wykorzystać dziedziczenie do rozwiązywania problemów, które są dużo lepiej adresowane przez inne mechanizmy języka. Najczęstszy błąd myślowy to uznawanie dziedziczenia za narzędzie "do wszystkiego" – a ono ma swoje bardzo konkretne, logiczne zastosowanie, głównie wtedy, gdy tworzysz strukturę klas od ogólnych do coraz bardziej szczegółowych. Po prostu warto od początku rozumieć, że dziedziczenie służy dokładnie temu – organizacji kodu wokół wspólnych cech i zachowań, nie zaś rozwiązywaniu każdego problemu napotkanego w kodzie.