Pytanie 1
Przyjmując, że opisana hierarchia klas właściwie odzwierciedla figury geometryczne i każda figura ma zdefiniowaną metodę do obliczania pola, to w której klasie można znaleźć deklarację metody liczPole()?
A. figura
B. trójkąt
C. trapez
D. czworokąt
Brak odpowiedzi na to pytanie.
Wyjaśnienie poprawnej odpowiedzi:
Deklaracja metody liczPole() powinna znajdować się w klasie bazowej, czyli w tym przypadku w klasie „figura”. To podejście jest zgodne z zasadami programowania obiektowego i tzw. polimorfizmem. Dzięki temu każda klasa dziedzicząca po „figurze” jest zobowiązana do własnej implementacji tej metody. To bardzo praktyczne rozwiązanie, bo umożliwia tworzenie ogólnych kolekcji (np. List<Figura>), które mogą przechowywać obiekty różnych figur, a następnie wywoływać liczPole() na każdym z nich bez zastanawiania się, jakiego typu to dokładnie obiekt. Z mojego doświadczenia wynika, że tak właśnie projektuje się API i biblioteki geometryczne – klasa bazowa narzuca kontrakt, a szczegóły są po stronie konkretnych figur. Warto dodać, że zgodnie z dobrymi praktykami, do deklarowania takich metod używa się słowa kluczowego „abstract”, co jasno komunikuje, że metoda musi być uzupełniona w klasach potomnych. Takie podejście mocno ułatwia rozbudowę kodu, np. kiedy chcemy dodać nowy typ figury, wystarczy, że nadpiszemy liczPole(). Moim zdaniem to jeden z najfajniejszych przykładów, jak dobrze przemyślana architektura kodu oszczędza czas i nerwy programistom.
Deklaracja metody liczPole() powinna znajdować się w klasie bazowej, czyli w tym przypadku w klasie „figura”. To podejście jest zgodne z zasadami programowania obiektowego i tzw. polimorfizmem. Dzięki temu każda klasa dziedzicząca po „figurze” jest zobowiązana do własnej implementacji tej metody. To bardzo praktyczne rozwiązanie, bo umożliwia tworzenie ogólnych kolekcji (np. List<Figura>), które mogą przechowywać obiekty różnych figur, a następnie wywoływać liczPole() na każdym z nich bez zastanawiania się, jakiego typu to dokładnie obiekt. Z mojego doświadczenia wynika, że tak właśnie projektuje się API i biblioteki geometryczne – klasa bazowa narzuca kontrakt, a szczegóły są po stronie konkretnych figur. Warto dodać, że zgodnie z dobrymi praktykami, do deklarowania takich metod używa się słowa kluczowego „abstract”, co jasno komunikuje, że metoda musi być uzupełniona w klasach potomnych. Takie podejście mocno ułatwia rozbudowę kodu, np. kiedy chcemy dodać nowy typ figury, wystarczy, że nadpiszemy liczPole(). Moim zdaniem to jeden z najfajniejszych przykładów, jak dobrze przemyślana architektura kodu oszczędza czas i nerwy programistom.
