Bot tutaj się nie popisał. Wrzuciłem pierwszy post:
Tak, w przedstawionym kodzie poprawnie używane jest polimorfizmu.
Polimorfizm polega na tym, że możliwe jest wywoływanie metod o tej samej nazwie dla różnych typów obiektów, które dziedziczą po tej samej klasie bazowej lub implementują tę samą interfejs. W przedstawionym przykładzie klasa Settings jest klasą bazową, a klasy ServerSettings i HostSettings dziedziczą po tej klasie i implementują metodę settings nadpisując ją.
W kodzie została zadeklarowana również metoda saveSettings w klasie Settings, która przyjmuje wskaznik na obiekt typu Settings i wywołuje na nim metodę settings. W klasach pochodnych ServerSettings i HostSettings została również zaimplementowana metoda saveSettings, która nadpisuje metodę z klasy bazowej i również wywołuje na obiekcie metodę settings. Dzięki temu możliwe jest wywoływanie metody saveSettings na obiektach różnych typów, które dziedziczą po klasie Settings, a kod wywołujący tę metodę nie musi znać dokładnego typu obiektu, na którym jest wywoływana.
Na koniec, w metodzie main tworzone są obiekty klas ServerSettings i HostSettings oraz przypisywany jest im wskaźnik s, a następnie wywoływana jest metoda saveSettings na obiektach przez ten wskaźnik. Dzięki temu, że obiekty te implementują nadpisaną wersję metody settings, wywoływana jest odpowiednia implementacja dla danego typu obiektu.
Ogólnie rzecz biorąc, w przedstawionym kodzie poprawnie używane jest polimorfizmu i implementacja tej techniki jest prawidłowa.
trochę go chciałem naprowadzić, ale tak sobie wyszło
Absolutnie nie, ten kod jest syntaktycznie poprawny ale semantycznie nie ma sensu. Napisz dlaczego.
W kodzie zaprezentowanym przez Ciebie zostały zaimplementowane metody settings i saveSettings w klasie bazowej Settings oraz ich nadpisane wersje w klasach pochodnych ServerSettings i HostSettings.
Metoda settings w klasie bazowej nie ma żadnego praktycznego zastosowania, ponieważ jej implementacja polega tylko na wyświetleniu komunikatu "brak ustawień" i nie wywołuje żadnych innych metod ani nie modyfikuje stanu obiektu. Natomiast metoda saveSettings w klasie bazowej przyjmuje wskaznik na obiekt typu Settings i wywołuje na nim metodę settings.
Z kolei w klasach pochodnych ServerSettings i HostSettings zostały zaimplementowane nadpisane wersje metod settings i saveSettings. W obu tych klasach metoda settings jest nadpisana i implementuje konkretne działanie, tj. wyświetlenie komunikatu "ustawienia serwera" lub "ustawienia hosta" w zależności od typu obiektu. Natomiast metoda saveSettings nadpisana w obu tych klasach również wywołuje metodę settings na przekazanym w argumencie obiekcie.
To sprawia, że w obu klasach pochodnych metoda saveSettings jest bezużyteczna, ponieważ wywołuje metodę settings, która i tak zostanie nadpisana przez konkretną implementację dla danego typu obiektu. W efekcie wywoływanie metody saveSettings na obiektach klas pochodnych nie ma żadnego praktycznego sensu, ponieważ jej działanie jest identyczne z wywoływaniem metody settings bezpośrednio.
Podsumowując, kod zaprezentowany przez Ciebie jest poprawny pod względem składni, ale semantycznie nie ma praktycznego sensu, ponieważ implementacja metod settings i saveSettings w klasach pochodnych jest zbędna i nieprzydatna.