W zaprezentowanym kodzie stworzono abstrakcyjną klasę figura oraz klasę prostokąta, która dziedziczy po niej, zawierającą zdefiniowane pola i konstruktory. Wskaż minimalną wersję implementacji sekcji /* metody klasy */ dla klasy Prostokat:
abstract class Figura { abstract double Pole(); abstract double Obwod(); } public class Prostokat extends Figura { private double a; private double b; ... /* Konstruktory */ ... /* Metody klasy */ } | |
| A | B |
public double Pole() { return a * b; } public double Obwod() { return 2*a + 2*b; } | public double Pole() { return a * b; } |
| C | D |
public double LiczPole() { return a * b; } public double LiczObwod() { return 2*a + 2*b; } | abstract double Pole() { return a * b; } abstract double LiczObwod() |
W tej sytuacji odpowiedź A to zdecydowanie najlepszy wybór. Dlaczego? Klasa Prostokat dziedziczy po abstrakcyjnej Figurze, która wymusza zaimplementowanie dwóch metod abstrakcyjnych: Pole() oraz Obwod(). W Javie (bo składnia sugeruje właśnie ją), jeżeli klasa nie zaimplementuje wszystkich metod abstrakcyjnych odziedziczonych po klasie abstrakcyjnej, sama musi być oznaczona jako abstract, a tu przecież Prostokat ma być konkretną klasą. Wersja A pokazuje dokładnie te dwie metody, z odpowiednimi nazwami, typami zwracanymi i poprawną logiką obliczeń: pole prostokąta to a * b, a obwód to 2*a + 2*b. Taki sposób pisania jest zgodny ze sztuką programowania obiektowego – spełniamy wymagania kontraktu narzuconego przez klasę bazową, implementujemy tylko to, co jest wymagane i w taki sposób, by użytkownik klasy mógł od razu wykorzystywać instancję Prostokata do obliczeń. Takie podejście bardzo ułatwia późniejsze rozbudowywanie projektu i współpracę z innymi programistami, bo każdy od razu wie, że Pole() i Obwod() są częścią wspólnego interfejsu wszystkich Figur. Moim zdaniem, w realnych projektach często się z czymś takim spotyka – jeśli tylko mamy dziedziczenie po klasie abstrakcyjnej, zawsze trzeba pamiętać o tych narzuconych metodach. Warto też zauważyć, że brak zbędnych dodatków – np. nadmiarowych metod czy zmienionych nazw – minimalizuje szansę na pomyłki i nieporozumienia w zespole. Tak w praktyce robi się solidną, czytelną bazę pod hierarchię figur geometrycznych.
Analizując pozostałe propozycje implementacji, łatwo zauważyć pewne typowe błędy, które pojawiają się podczas pracy z dziedziczeniem i klasami abstrakcyjnymi. Przede wszystkim odpowiedzi, które pomijają implementację jednej z metod abstrakcyjnych zadeklarowanych w klasie Figura (jak w przypadku wariantu B), nie spełniają podstawowego wymogu języka Java – klasa pochodna musi zaimplementować wszystkie metody zadeklarowane jako abstract w klasie bazowej. W odpowiedzi B mamy tylko metodę Pole(), więc przy próbie kompilacji kodu pojawiłby się błąd i konieczność oznaczenia Prostokata jako klasy abstrakcyjnej, co zupełnie mija się z celem. Z kolei odpowiedź C wprowadza metody o innych nazwach (LiczPole, LiczObwod) niż te zadeklarowane w klasie Figura. To bardzo częsty błąd początkujących – niepoprawnie myślą, że wystarczy zaimplementować metody o tej samej funkcjonalności, bez zachowania ich nazw. Tymczasem kontrakt narzucony przez klasę bazową musi być spełniony dokładnie, razem z nazwami, typami argumentów i zwracanym typem. Ignorowanie tych szczegółów prowadzi do niespójności i niekompatybilności klas pochodnych. No i ostatnia propozycja – D – zawiera próbę napisania metody z modyfikatorem abstract w klasie, która już nie jest abstrakcyjna, co jest wprost błędem kompilacji. Dodatkowo, używanie abstract razem z ciałem metody jest niezgodne z językiem – metody abstrakcyjne nie mogą mieć implementacji w klasie abstrakcyjnej, a tym bardziej w pochodnej. To wszystko pokazuje, jak ważne w programowaniu obiektowym jest zrozumienie zasad dziedziczenia, poprawnego nadpisywania metod oraz konsekwentne trzymanie się sygnatur narzucanych przez klasy bazowe. Z praktyki wiem, że takie błędy potrafią zablokować rozwój projektu albo wymusić czasochłonne refaktoryzacje. Warto od początku przyzwyczaić się do czytania kodu bazowego i dokładnego kopiowania sygnatur metod – to oszczędza dużo nerwów i nieporozumień w pracy zespołowej.