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.