Dans ton problème, tu prends la relation d'héritage à chaque fois que tu peux dire « est-un ». C'est une simplification qui est souvent utilisée pour enseigner l'OO mais rarement expliquée comme telle.
Java a été conçu après 20 ans d'expériences en POO, après que l'on a pu conceptualiser pas mal de zones d'ombre. Et, à ce moment, l'on s'était rendu compte que l'héritage multiple posait beaucoup de problèmes et qu'il fallait faire une différence entre l'héritage de structure (classes) et l'héritage de comportements (interfaces). On s'est aussi rendu compte que la majorité des problèmes de l'héritage multiple sont dus à l'héritage multiple de structures (problèmes de l'héritage en diamant, p.ex.). On s'est aussi rendu compte que les autres cas d'héritage multiple sont relativement rares (comparativement aux ennuis) et facilement contournables par délégation.
Maintenant, on s'apperçoit qu'il y a d'autres problèmes en POO, comme les aspects p.ex.
Pour en revenir à ton exemple précis (que j'ai eu du mal à obtenir hier, d'où une réponse seulement aujourd'hui), tu fais plusieurs choix discutables, p.ex. que Laguna est une classe et que Renaut est une classe. Voiture est bien une classe, mais Renault est une instance de la classe Constructeur et Laguna une instance de la classe Modèle. Voiture aura donc deux attributs : constructeur et modèle.
Alors tu me répondras : c'est de la délégation, c'est plus joli avec de l'héritage. Mais l'héritage n'a rien à voir dans ces relations. Le fait que tu puisses remplacer de l'utilisation (composition/aggrégation) par de l'héritage et que cela soit plus court à écrire n'est pas une raison pour le faire. Conceptuellement, ça ne tient pas.
[^] # Re: Mes deux centimes ...
Posté par Sylvain Sauvage . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 6.
Java a été conçu après 20 ans d'expériences en POO, après que l'on a pu conceptualiser pas mal de zones d'ombre. Et, à ce moment, l'on s'était rendu compte que l'héritage multiple posait beaucoup de problèmes et qu'il fallait faire une différence entre l'héritage de structure (classes) et l'héritage de comportements (interfaces). On s'est aussi rendu compte que la majorité des problèmes de l'héritage multiple sont dus à l'héritage multiple de structures (problèmes de l'héritage en diamant, p.ex.). On s'est aussi rendu compte que les autres cas d'héritage multiple sont relativement rares (comparativement aux ennuis) et facilement contournables par délégation.
Maintenant, on s'apperçoit qu'il y a d'autres problèmes en POO, comme les aspects p.ex.
Pour en revenir à ton exemple précis (que j'ai eu du mal à obtenir hier, d'où une réponse seulement aujourd'hui), tu fais plusieurs choix discutables, p.ex. que Laguna est une classe et que Renaut est une classe. Voiture est bien une classe, mais Renault est une instance de la classe Constructeur et Laguna une instance de la classe Modèle. Voiture aura donc deux attributs : constructeur et modèle.
Alors tu me répondras : c'est de la délégation, c'est plus joli avec de l'héritage. Mais l'héritage n'a rien à voir dans ces relations. Le fait que tu puisses remplacer de l'utilisation (composition/aggrégation) par de l'héritage et que cela soit plus court à écrire n'est pas une raison pour le faire. Conceptuellement, ça ne tient pas.