Wskaż właściwość charakterystyczną dla metody abstrakcyjnej?
Metoda abstrakcyjna to taki specjalny rodzaj metody, który pojawia się w programowaniu obiektowym, głównie w językach jak Java, C# czy Python (tam nazywa się abstractmethod). Jej kluczową właściwością jest to, że nie ma własnej implementacji w klasie bazowej, czyli tej nadrzędnej. To trochę jakby ktoś powiedział: 'Hej, tutaj powinna być jakaś funkcja, ale jeszcze nie wiem, jak dokładnie ma działać – niech ktoś, kto będzie po mnie dziedziczył po tej klasie, sam ją zdefiniuje.' Dzięki temu daje się klasom pochodnym jasny sygnał, że muszą tę metodę zaimplementować, żeby klasa mogła poprawnie funkcjonować. W praktyce, jeśli próbujesz stworzyć obiekt klasy bazowej zawierającej metody abstrakcyjne, kompilator się obrazi (no, rzuci wyjątkiem albo nawet nie pozwoli na kompilację). Moim zdaniem to bardzo praktyczne podejście, bo wymusza spójność w architekturze kodu – każdy, kto dziedziczy po klasie bazowej, nie może zapomnieć o kluczowych metodach. Standardy branżowe, jak SOLID, promują taką separację odpowiedzialności i abstrakcję, dzięki czemu kod jest czytelniejszy i łatwiejszy do rozbudowy. Przykładowo, jeśli masz klasę abstrakcyjną 'Figura', to metoda obliczPole() nie ma sensu bez konkretnej figury, więc w klasie bazowej zostaje abstrakcyjna, a dopiero w 'Kwadracie' czy 'Kole' dostaje realną implementację. Z mojego doświadczenia, takie podejście bardzo pomaga, kiedy projekt robi się większy, bo jasno wiadomo, co jeszcze trzeba dopisać w klasach pochodnych. Jest to wręcz obowiązkowe w wielu wzorcach projektowych, na przykład w strategii albo szablonie metody.
Wokół metod abstrakcyjnych narosło sporo nieporozumień, które często wynikają z mieszania pojęć związanych z dziedziczeniem i modyfikatorami dostępu. Ludzie czasem myślą, że metoda abstrakcyjna musi być zawsze prywatna, co jednak mija się z prawdą – przecież klasa pochodna nie miałaby do niej dostępu i nie mogłaby jej zaimplementować, gdyby była private. Standardy języków jak Java czy C# wręcz wymagają, by była minimum protected albo public, żeby dziedziczące klasy mogły ją nadpisać. Często można się też spotkać z przekonaniem, że metoda abstrakcyjna jest pusta w klasach dziedziczących – a to bardzo mylące, bo właśnie w klasach dziedziczących mamy obowiązek podać jej konkretną implementację. Jeżeli to pominiesz, kompilator przypomni o tym błędzie. Pojawia się też pogląd, że metoda abstrakcyjna jest pusta w klasie nadrzędnej – to nieprecyzyjne ujęcie, bo 'pusta' sugeruje, że można mieć ciało metody, tylko nic w nim nie napisać, a tymczasem w przypadku metody abstrakcyjnej w ogóle nie wolno podawać ciała w klasie bazowej (nawet klamerek!). Typowym błędem jest też mylenie metody abstrakcyjnej z tzw. metodą wirtualną lub domyślną (te już często mają jakąś domyślną implementację, którą można nadpisać). Takie nieporozumienia prowadzą potem do źle zaprojektowanych hierarchii klas, co z czasem utrudnia rozwój projektu. Z mojego doświadczenia wynika, że najlepiej po prostu pamiętać: metoda abstrakcyjna to taka, która nie ma implementacji w bazie i wymusza jej podanie w klasie pochodnej. Tyle, żadnych półśrodków czy wyjątków.