Co to jest klasa abstrakcyjna?
A. Klasa, która nie może mieć żadnych metod
B. Klasa, która może być dziedziczona, ale nie można utworzyć jej obiektu
C. Klasa, która nie może zawierać metod wirtualnych
D. Klasa, która zawsze dziedziczy z klasy bazowej
Klasa abstrakcyjna to taki typ w programowaniu obiektowym, który służy jako baza dla innych klas, ale sam nie powinien być tworzony jako gotowy obiekt. Czyli można po niej dziedziczyć, ale nie można zrobić czegoś w stylu new KlasaAbstrakcyjna, jeśli język na to nie pozwala, np. w Javie, C# czy C++. Ma to sens praktyczny: taka klasa opisuje wspólne cechy i zachowania, ale często jest zbyt ogólna, żeby istniała samodzielnie. Przykład: abstrakcyjna klasa Pojazd może mieć pola prędkość, masa i metodę jedź, ale konkretnymi obiektami będą Samochód, Rower albo Autobus. W dobrych praktykach OOP używa się klas abstrakcyjnych do modelowania wspólnego kontraktu i częściowej implementacji. Moim zdaniem to jeden z ważniejszych mechanizmów przy projektowaniu większych aplikacji, bo pomaga unikać duplikacji kodu i porządkuje hierarchię klas. Klasa abstrakcyjna może zawierać normalne metody, pola, konstruktory, metody wirtualne oraz metody abstrakcyjne, zależnie od języka. Ważne jest to, że wymusza na klasach potomnych doprecyzowanie zachowania, którego sama nie potrafi sensownie wykonać.
W tym pytaniu łatwo pomylić kilka pojęć z programowania obiektowego, szczególnie jeśli ktoś kojarzy słowo abstrakcyjna jako coś niekonkretnego i próbuje zgadywać na podstawie samej nazwy. Klasa abstrakcyjna nie oznacza klasy pustej ani takiej, która nie może mieć metod. Wręcz przeciwnie, bardzo często zawiera normalne metody z gotową implementacją, pola, właściwości, konstruktory pomocnicze, a czasem także metody abstrakcyjne, które dopiero klasy potomne muszą zaimplementować. W praktyce jest to szablon logiczny dla innych klas, a nie zakaz pisania metod. Błędne jest też przekonanie, że klasa abstrakcyjna nie może zawierać metod wirtualnych. W wielu językach, na przykład w C#, metody wirtualne i abstrakcyjne są wręcz związane z polimorfizmem, czyli możliwością wywoływania różnych implementacji przez wspólny typ bazowy. To jest normalny i bardzo użyteczny mechanizm. Nie należy też zakładać, że klasa abstrakcyjna zawsze dziedziczy z jakiejś klasy bazowej. Może być podstawą hierarchii sama z siebie, choć technicznie w niektórych językach każda klasa i tak pośrednio dziedziczy po typie ogólnym, na przykład Object. To jednak nie jest cecha definiująca abstrakcyjność. Sedno sprawy jest inne: takiej klasy nie instancjonujemy bezpośrednio, tylko używamy jej jako wspólnej bazy dla bardziej konkretnych klas. Z mojego doświadczenia wynika, że najczęstszy błąd polega na myleniu klasy abstrakcyjnej z interfejsem albo z klasą bazową w ogóle. Dobra praktyka jest taka, żeby stosować klasy abstrakcyjne wtedy, gdy chcemy współdzielić część kodu i jednocześnie wymusić pewien kontrakt zachowania u klas dziedziczących.