J'ai une petite question, sur ce sujet, lmghs dit : "j'aimerai vérifier si ses PointColoré sont toujours des Point (erreur de conception)", ma question est donc : en quoi est-ce une erreur de conception ? (si c'est bien le cas en général, ou si c'est propre a ce cas)
Pour moi, un point coloré possède bien toutes les propriétés du point (tous en en rajoutant une), et peut bien être utiliser en substitution à un objet Point. Je n'arrive donc pas a voir l'erreur de conception ?
Il semble aussi parfaitement possible de simplement intégré dans la class/struct PointColore un attribut Point.
Merci d'avance pour votre lecture et/ou explication
Si PC{1,2,Vert} == P{1,2} et que PC{1,2,rouge} == P{1,2}, cela veut dire que PC{1,2,vert} == PC{1,2,rouge}, non?
Points et PointColorés sont des classes qui sont typiquement à sémantique de valeur, i.e. comparable.
Quels est le contrat de l'égalité? - réflexivité: x == x - symétrie: x == y <=> y == x - transitivité: x == y et y == z => x == z
Rajoutons l'héritage, cela veut dire que l'on veut permettre de manipuler identiquement parents et enfants sans faire de distinction. Je simplifie, mais le terme clé à googler est "Principe de Substitution de Liskov" (aka LSP).
La conclusion est que l'on ne peut pas avoir comparaison (le propre des valeurs) et héritage public qui vérifie le LSP en même temps (un héritage qui ne vérifie pas le LSP est un bug de conception latent).
Je l'ai fait court, très court. La démonstration complète, tu la trouveras dans "Effective Java" de Joshua Bloch. Il a un chapitre (entier je crois) dédié au sujet -- car Java souffre d'un problème avec son top-type Object (dont toute classe dérive) et qui définit la méthode equals(). Le problème se pose aussi avec le hashage.
La conclusion est que un point coloré peut être défini à partir d'un point par composition (Java, C++...), ou par héritage privé (C++), mais pas par "héritage public" (C++) ou "héritage" (tous les autres langages). Ou alors on affirme qu'ils ne sont pas comparables et qu'ils sont plus des particules qui peuvent se déplacer ou changer de couleur, bref des entités et plus des valeurs.
Là où je chouine, c'est que beaucoup de cours emploient cet exemple pour présenter l'héritage. C'est un exemple simple à présenter, mais un exemple qui présente une faille de conception vicieuse. Qui plus est il met l'accent sur la mauvaise chose: il démontre la factorisation des données. Tout l'intérêt de la conception OO (au delà d'abstraction et encapsulation que l'on trouvait déjà autrement et différemment), c'est la factorisation des comportements. Pas des données. Pour cela, le tuto de ZdS suit la bonne voie -- bon OK, je suis parti pris, ils ont repris mon exemple de balais & aspirateurs.
Je n'avais clairement pas penser a la faille de la comparaison (même si j’avais essayer de vérifier rapidement si les principes SOLID étaient vérifier, je manque encore cruellement expérience), c'est exactement ce que je voulais savoir.
Bon. Avoir un langage qui fait la distinction aide. Ce n'est pas le cas des langages mainstreams. A la limite le C++ a un héritage (privé) qui n'implique pas le sous-typage.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
GitHub
GitHub