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()

Wyjaśnienie

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.