Hej,
Mam zaprojektować diagram klas, a tak naprawdę dziedziczenie dla trzech klas: człowiek, student, **absolwent **.
Jak waszym zdaniem powinno wyglądać dziedziczenie?
- Człowiek <-- Student <-- Absolwent
czy - Student --> Człowiek <-- Absolwent
0
1
To zależy od zasady podstawiania, czyli finalnie od tego jak chcesz ich używać. Opcja 2 wydaje się o tyle sensowniejsza, że absolwent niekoniecznie pasuje wszędzie tam gdzie student. Absolwent np. nie może iśc na egzamin, więc gdybyś miał metodę piszEgzamin(Student student) to wstawienie do niej Absolwenta nie miało by sensy, więc zasada podstawiania nie byłaby spełniona.
W efekcie nie ma jednoznacznej odpowiedzi, jeśli nie wiemy nic więcej.
0
@Shalom: Dzięki za odpowiedź.
Zadanie jest czysto teoretyczne, wzięte z kolokwium.
Klasa absolwent miała wszystkie pola z klasy Student, co teoretycznie można uzyskać opcją 1. Jednakże twierdzę, że Absolwent nie jest specjalnym rodzajem Studenta.
0
Ja w ogóle zastanowiłbym się czy dziedziczyć czy jednak nie robić kompozycji/dekoracji ;) No i tak jak napisałem wyżej, pola to nie wszystko, bardziej istotna jest kwestia zachowania zasady podstawiania, bo to ona określa czy X jest speecjalnym rodzajem Y czy też nie jest.
Wyobraź sobie klasę Punkt oraz Wektor. Z punktu widzenia pól te klasy mogą być takie same, ot mają jakiś x oraz y, ale te wartości oznaczają co innego, a co więcej nie można używać punktu w miejscu wektora ani odwrotnie, bo zwyczajnie nie będzie to miało sensu. Nie można wrzucić Punktu do metody liczącej długość wektora, bo wyjdą nam głupoty, z drugiej strony nie można wrzucić Wektora do metody liczacej odległośc punktu od prostej, bo znów dostaniemy jakieś wartości liczbowe, które nic nie znaczą.
1
Ja tu nie widzę dziedziczenia, ale pewnie to nie będzie prawidłowa odpowiedź na twoim kolokwium z programowania obiektowego.
Student opisuje relację między człowiekiem i uczelnią. Nie można zmieniać typu obiektu w czasie jego życia, więc jak chciałbyś „stać” człowieka studentem/absolwentem?
Zawsze jak chciałem wprowadzić statyczne typy w obiektach reprezentujących fizyczne rzeczy, to przegrywałem z nowymi nieoczekiwanymi wymaganiami, gdzie nagle te rzeczy mogły nabywać typy w sposób dynamiczny.
No i przede wszystkim, OOP wbrew popularnemu poglądowi nie jest modelowaniem fizycznych rzeczy za pomocą obiektów.