Hej, mam takie pytanie czy poprawnym jest aby Szklanka dziedziczyła Uchwyt? Albo aby ZegarCyfrowy dziedziczył Wyświetlacz?
Np chciałbym wykonać operacje na wyświetlaczu obiektu. Nie interesuje mnie czy to telefon, czy zegar cyfrowy czy lodówka.
Programuje w Java ale chyba nie ma to znaczenia.
Z góry dziękuję za pomoc.
Nie. Wyświetlacz jest CZĘŚCIĄ Zegara.
class Clock{
private final Display display;
//
}
Dziedziczenie stosujesz, kiedy coś jest specjalizacją danej klasy. Przykładowo klasa pies jest specjalizacją klasy zwierzę, ale już błędem byłoby powiedzenie, że pies jest częścią zwierzęcia.
Kompozycję stosujesz, kiedy obiekt jednej klasy zawiera w sobie obiekt drugiej klasy, czyli przykładowo właśnie wyświetlacz jest częścią zegara. Natomiast wyświetlacz nie jest specjalizacją zegara.
Pomyślałem sobie, że to zależy od problemu jaki się ma, może nie trzeba się trzymać analogii do rzeczywistych obiektów.
hycel99 napisał(a):
Pomyślałem sobie, że to zależy od problemu jaki się ma, może nie trzeba się trzymać analogii do rzeczywistych obiektów.
Raczej trzeba, a akurat te przypadki, które podałeś są bardzo klarowne.
Generalnie jeśli masz klasę X i zastanawiasz się jaki rodzaj ponownego użycia tej klasy zastosować w stosunku do klasy Y, to zadaj sobie pytanie, czy obiekty klasy Y są w rzeczywstości także typem X. Jeśli tak - stosuj dziedziczenie.
Generalnie należy preferować kompozycję od dziedziczenia, wtedy się łatwiej połapać zarówno przeglądając kod, jak i co ważniejsze później próbując zmienić, jeśli się okaże, że... no zegar cyfrowy jednak nie powinien dziedziczyć po wyświetlaczu.
Można się w tym przypadku też zastanowić nad interfejsami, np ;-) IChwytable i IWyswietlaczable :-D (oczywiście te nazwy tylko dla żartu).
A analogi nie musisz się trzymać, ale ma zwykle sens zbadać domenę. Jeśli domeną jest otaczający świat i źle dobierzesz dziedziczenie, to później może być problem, jak będzie zegar cyfrowy z wyświetlacza dziedziczył, smartfon też... a tu nagle okaże się że chcesz mieć "Stary" telefon bez wyświetlacza... i wypadałoby żeby smartfon z niego dziedziczył.. robi się problem. Tak samo jak chcesz mieć nagle szklankę z uchwytem i bez... i wypada żeby ta z uchwytem dziedziczyła po tej bez.
I tu jak wyżej napisałem pomaga kompozycja zamiast dziedziczenia.
Model złożony z dwóch albo trzech klas jest dość ciężko zepsuć, bo okaże się że wiele rzeczy pasuje i będzie działać... aż do momentu jak trzeba dodać ich więcej. Wtedy się okazuje że początkowe założenia trzeba zweryfikować, warto sobie zostawić furtkę do łatwych zmian w przyszłości.
Lepiej zdecydowanie wybierac kompozycję nad dziedziczenie, nawet jesli "jest" jest prawda :)
Dziedziczenie bardzo ogranicza, tworzy silne powiązania między klasami, jesli zmieniasz API klasy bazowej często jesteś zmuszany zmieniac API klasy dziedziczącej i łatwo sie wywalić, jak w tym przykładzie:
https://medium.com/@rufuszh90/effective-java-item-16-favour-composition-over-inheritance-ed82e482fd1a
Kompozycja + interfejsy > dziedziczenie
hycel99 napisał(a):
Hej, mam takie pytanie czy poprawnym jest aby Szklanka dziedziczyła Uchwyt? Albo aby ZegarCyfrowy dziedziczył Wyświetlacz?
Np chciałbym wykonać operacje na wyświetlaczu obiektu. Nie interesuje mnie czy to telefon, czy zegar cyfrowy czy lodówka.
Wyświetlacz to część zegara - kompozycja.
Uchwyt to deklaracja istnienia jakiejś funkcjonalności, interface + jego implementacja. Ewentualnie może być to osobny obiekt, implementujący ten interface, który jest częścią kubka (czyli też kompozycja).
Użycie dziedziczenia na poziomie klas jest raczej passe, szczególnie w Javie, gdzie prędzej czy później rozbijesz się o problem, czy telewizor jest bardziej meblem, czy urządzeniem.