To właśnie jest klasyczny przykład dziedziczenia w programowaniu obiektowym. W tym przypadku mamy bazową klasę 'Owoc', z której dziedziczą klasy 'Truskawka' oraz 'Jablko'. Dzięki temu możemy zdefiniować wspólne cechy i zachowania dla wszystkich owoców w jednej klasie, a potem rozszerzać je w bardziej szczegółowych klasach. Moim zdaniem to jedno z najwygodniejszych założeń OOP, bo pozwala pisać kod, który jest łatwiejszy do utrzymania i rozbudowy. Jeśli kiedyś dołożysz nową funkcjonalność do wszystkich owoców, nie musisz jej wrzucać oddzielnie do każdej odmiany, tylko wystarczy, że zrobisz to raz w klasie 'Owoc'. To bardzo zgodne ze standardami SOLID i ogólnie dobrą praktyką DRY (Don't Repeat Yourself). W realnych aplikacjach, np. systemach do zarządzania magazynem, dziedziczenie pozwala łatwo rozróżnić typy produktów, a jednocześnie trzymać wspólny kod w jednym miejscu. Warto też pamiętać, że dziedziczenie to podstawa do późniejszego korzystania z polimorfizmu. Jeśli chcesz, żeby jakieś metody działały różnie w zależności od konkretnego typu owocu, wystarczy je nadpisać w podklasach. W sumie – nie da się pisać sensownych aplikacji obiektowych bez znajomości dziedziczenia, bo to daje ogromną elastyczność i porządek w kodzie.
W tym przykładzie kodu nie chodzi ani o polimorfizm, ani abstrakcję, ani hermetyzację, choć to wszystko są bardzo ważne pojęcia w programowaniu obiektowym. Polimorfizm polega na tym, że obiekty różnych klas mogą być traktowane tak samo poprzez wspólny interfejs, a konkretne zachowanie jest wybierane w czasie działania. Jednak w pokazanym kodzie nie mamy żadnych metod ani przykładu dynamicznego wywołania tej samej funkcji na różnych typach, więc nie występuje tutaj polimorfizm w praktycznym sensie. Jeśli chodzi o abstrakcję, to jest to wyodrębnianie wspólnych cech i zachowań do bardziej ogólnej klasy lub interfejsu, często z użyciem klas abstrakcyjnych lub interfejsów. W tym przypadku nie zastosowano ani słowa kluczowego 'abstract', ani nie przedstawiono żadnych metod abstrakcyjnych, więc kod nie wskazuje na abstrakcję. Hermetyzacja natomiast polega na ukrywaniu szczegółów implementacji klasy, najczęściej przez stosowanie modyfikatorów dostępu i enkapsulację pól (np. private fields i publiczne gettery/settery). Tutaj nie ma żadnych pól, metod ani kontroli dostępu, więc o hermetyzacji też nie można mówić. W moim odczuciu, często te pojęcia się mylą, bo są mocno powiązane, ale kluczowe jest, żeby rozpoznawać konkretne mechanizmy po zapisie kodu – a przykład dosłownie pokazuje dziedziczenie, bo nowe klasy rozszerzają jedną wspólną klasę bazową. To dobry moment, żeby jeszcze raz wrócić do podstaw i upewnić się, czym objawia się każde z tych pojęć w praktyce.