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: <table><tr><td colspan="2">abstract class Figura { abstract double Pole(); abstract double Obwod(); } public class Prostokat extends Figura { private double a; private double b; ... /* Konstruktory */ ... /* Metody klasy */ }</td></tr><tr><td>A</td><td>B</td></tr><tr><td>public double Pole() { return a * b; } public double Obwod() { return 2*a + 2*b; }</td><td>public double Pole() { return a * b; }</td></tr><tr><td>C</td><td>D</td></tr><tr><td>public double LiczPole() { return a * b; } public double LiczObwod() { return 2*a + 2*b; }</td><td>abstract double Pole() { return a * b; } abstract double LiczObwod()</td></tr></table>

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.