Discussion :

[hegros]

Je n'ai pas dit que cela permet à une pomme d'avoir une fonction freine, j'ai dit que tu peux appeler les fonctions présentées par Object (essentiellement equals ) en ayant d'un coté une pomme et de l'autre une voiture...

Or, cela n'a strictement aucun sens

Je ne comprends pas en quoi cela n'a pas de sens puisque le sens de l'égalité c'est une liberté d'implémentation qui est donnée au développeur quand bien même il existe un comportement par défaut. De plus lorsque tu appelles Equals tu ne le fais pas sur une voiture ou une pomme mais sur un Object ce qui est différent


Et avec de l'imagination on pourrait donner un sens. Allez soyons fou, imaginons que nous soyons dans un jeu vidéo où des pommes se déguisent en voiture ou l'inverse et qu'en passant la souris sur l'objet on veuille dessiner sa vraie forme if (voiture == pomme) voiture.RedrawWithOriginalForm(pomme);

Magnifique non On pourra toujours faire autrement mais montre une autre façon de faire et j'en trouverais une autre

Le problème, c'est qu'avec java, si tu te demande quel est le plus petit commun à deux classes, tu retomberas systématiquement sur Object, alors qu'en C++, tu restes libre de décider quel est ce plus petit commun (avec, il est vrai, le risque de partir sur un God Object equivalent )

En même temps le framework standard du C++ n'est certainement pas aussi élaboré et développé que celui du C# ou de Java et il ne se manipule certainement pas avec autant de simplicité. Et la maintenabilité (80% du coût d'un logiciel)n'est certainement pas autant aisé en C++ comparé au Java ou C#.

[hegros]

Et avec de l'imagination on pourrait donner un sens. Allez soyons fou, imaginons que nous soyons dans un jeu vidéo où des pommes se déguisent en voiture ou l'inverse et qu'en passant la souris sur l'objet on veuille dessiner sa vraie forme if (voiture == pomme) voiture.RedrawWithOriginalForm(pomme);

Pour les puristes de la conception, ceci n'est qu'un exemple qui tente d'apporter des arguments contradictoires (trop facile sinon). Donc non il n'y aurait pas de méthode RedrawWithOriginalForm dans une voiture

plutôt un code du style :

static RedrawOriginalForm (Object currentForm, Object hiddenForm) ;

voir

static RedrawOriginalForm(Car car, Apple apple);

voir après en C# avec des méthodes d'extensions mais ici c'est c++ vs java

[spidermario]

[D]'ailleurs chez Qt on a aussi choisi de tout faire hériter d'un QObject, ça permet au framework de s'appuyer sur une série de fonctions de base.

En fait, tout n’est pas un QObject. Seules les entités en sont mais pas les valeurs (donc pas QString ni QList ni…).

http://developer.qt.nokia.com/doc/qt...ntity-vs-value

[koala01]

Je ne comprends pas en quoi cela n'a pas de sens puisque le sens de l'égalité c'est une liberté d'implémentation qui est donnée au développeur quand bien même il existe un comportement par défaut. De plus lorsque tu appelles Equals tu ne le fais pas sur une voiture ou une pomme mais sur un Object ce qui est différent

Mais c'est, justement, sur ce que j'ai mis en gras qu'est le problème!!!

Le principe même de l'héritage, c'est de pouvoir substituer, dans toute fonction prenant (une référence ou un pointeur sur) un objet du type de la classe mère, un (pointeur ou une référence sur) un objet du type de n'importe quel classe dérivée que ce soit de manière directe ou indirecte.

Or, même si on peut considérer que voiture hérite de véhicule, on ne devrait même pas pouvoir comparer une voiture avec un véhicule, de manière générale, car cela permet de la comparer avec un camion ou avec un vélo et cela n'a déjà pas de sens!

Si on veut comparer une voiture à autre chose, cela n'a de sens de le faire qu'avec une voiture, et rien d'autre!

Dés lors, en arriver à pouvoir comparer une voiture avec "n'importe quoi d'autre" (y compris une pomme!!!) du fait d'un héritage de base commun n'a, fatalement, encore moins de sens!

Et avec de l'imagination on pourrait donner un sens. Allez soyons fou, imaginons que nous soyons dans un jeu vidéo où des pommes se déguisent en voiture ou l'inverse et qu'en passant la souris sur l'objet on veuille dessiner sa vraie forme if (voiture == pomme) voiture.RedrawWithOriginalForm(pomme);

Ce n'est, justement, pas à la pomme de décider comment se dessiner, et encore moins, de décide de la forme sous laquelle elle sera dessinée.

Si tu donnes à la pomme la responsabilité de décider de la forme sous laquelle elle devra être dessinée, tu lui donnes une responsabilité supplémentaire à sa responsabilité de base qui est... de représenter une pomme.

Et le problème, c'est qu'à partir du moment où la pomme aura cette double responsabilité (sans doute parce que tu auras fait hérité de manière directe ou indirecte pomme de "CamoufableEtTracable qui hériitera lui-même de Tracable et implémentera Camoufable (ou l'inverse, qui sait ), tu te diras qu'il n'y a pas de mal à lui donner une responsabilité supplémentaire (quelle qu'elle soit), et tu t'engages dés lors sur quelque chose qui ne peut que "partir en sucette" et devenir impossible à faire évoluer et à maintenir

La meilleure preuve de ce que j'avance, c'est que, si tu en arrives à ce point, c'est que tu auras déjà donné une autre responsabilité supplémentaire à ta pomme qui est celle de réagir au survol de la souris!!!


Non, si quelque chose doit décider de la forme sous laquelle la pomme sera dessinée, c'est le système qui devra réagir à l'événement du survol, voir, à l'état que ce survol implique

Magnifique non On pourra toujours faire autrement mais montre une autre façon de faire et j'en trouverais une autre

N'importe quel système de gestion cohérent d'état ayant comme membre une pomme, une éventuelle notion de camouflage et qui sera utilisé par n'importe quel système d'affichage prenant la hiérarchie des objets du type "gestionnaire d'état" comme argument lors de l'affichage

En même temps le framework standard du C++ n'est certainement pas aussi élaboré et développé que celui du C# ou de Java et il ne se manipule certainement pas avec autant de simplicité. Et la maintenabilité (80% du coût d'un logiciel)n'est certainement pas autant aisé en C++ comparé au Java ou C#.

Il y a surement nature à débat quant à savoir ce que le langage doit apporter "de base"

Je suis plutot partisan d'un aspect "minimaliste" (comprends : je ne suis pas sur que fournir un framework permettant la création d'IHM par exemple soit encore du scope du langage ), à charge pour "la communauté" de développer ce qui les intéresse en fonction de leur propre philosophie

Et, ceci dit, si tu t'arrêtes juste à ce qui est fournis par le langage (comprend : ce qui se trouve, en gros, dans l'espace de noms std ), c'est généralement d'une simplicité enfantine (ou peu s'en faut)

Quant à la maintenabilité du projet, elle va surtout dépendre de la compétence de l'équipe de développement et de choix de bases faits à tord ou à raison...

Mais, l'un dans l'autre, s'il est sans doute plus facile d'arriver à quelque chose de complètement impossible à maintenir en C++, il ne faut pas croire qu'il soit *si difficile que cela* d'y arriver en java ou en C# : une mauvaise analyse ou de mauvais choix à la base finiront toujours par nuire à la maintenabilité, quel que soit le langage envisagé

[hegros]

car cela permet de la comparer avec un camion ou avec un vélo et cela n'a déjà pas de sens!

Si on veut comparer une voiture à autre chose, cela n'a de sens de le faire qu'avec une voiture, et rien d'autre!

Je ne suis franchement pas d'accord et convaincu. Pourquoi on ne pourrait pas comparer un camion avec un vélo ? La comparaison est une liberté d'implémentation et chacun donne le sens qu'il veut en fonction de son besoin.

Ta perception me semble bien rigide et fermé.

Ce n'est, justement, pas à la pomme de décider comment se dessiner, et encore moins, de décide de la forme sous laquelle elle sera dessinée.

J'ai déjà répondu (en anticipant) à cela dans mon dernier message précédent le tien..

[koala01]

Je ne suis franchement pas d'accord et convaincu. Pourquoi on ne pourrait pas comparer un camion avec un vélo ? La comparaison est une liberté d'implémentation et chacun donne le sens qu'il veut en fonction de son besoin.

Ta perception me semble bien rigide et fermé.

Pas quand on parle de la comparaison d'égalité!!! il est clair et évident que si tu compare (dans un test d'égalité) une voiture avec n'importe quoi d'autre, tu n'arriveras de toutes manière jamais à un résultat positif!


Et, surtout, même en faisant preuve de beaucoup d'imagination, quel critère pourrais tu bien trouver pour tester l'(in)égalité entre une pomme et une voiture sans en arriver à ne dénaturer ni l'un ni l'autre

L'adresse mémoire à laquelle se trouve la variable il va de soi que jamais au grand jamais l'adresse d'une pomme ne sera identique à celle à laquelle se trouve une voiture...

La couleur, ou le poids C'est oublier un peu vite que ce ne sont vraiment pas des facteurs discriminants

Une quelconque propriété propre aux pommes ou propre aux voitures Coment vas tu gérer l'absence de cette propriété dans "l'autre type"

Tu trouves que je suis rigide et fermé prouves moi que j'ai tord en m'indiquant un moyen même très imaginatif pour faire une comparaison d'égalité entre une voiture et une pomme qui tienne un minimum la route (au sens OO s'entend ), et je reverrai ma position

[hegros]

Pas quand on parle de la comparaison d'égalité!!! il est clair et évident que si tu compare (dans un test d'égalité) une voiture avec n'importe quoi d'autre, tu n'arriveras de toutes manière jamais à un résultat positif!

On se donnant la peine de chercher on pourrait trouver, c'est simplement une question de domaine/métiers et certainement pas une question OO.

Allez soyons joueur, a l'esprit ce qui me vient : le résultat ne sera pas toujours positif dans la mesure où par exemple le test concerne si un objet est périssable ou pas.

Le résultat de l'égalité devient donc positif entre une voiture et du sel ou une voiture et un livre ou une voiture et une boîte de pois chiche....

Avant de hurler à la fausse égalité quelques précisions :

-Partons du principe simpliste que périssable = bio-dégradable

-Partons du principe qu'il existe des voitures bio-dégradable bien que cela n'a pas encore de valeur légale à ce jour mais que dans un futur cela pourrait très bien être possible

-Il existe au moins une voiture bio-dégradable (utilisez votre moteur de recherche) conceptualisée et mise en œuvre par un fabricant (ce qui rends le test réaliste)

La couleur, ou le poids C'est oublier un peu vite que ce ne sont vraiment pas des facteurs discriminants

Quelle est ta définition de 'facteur discriminant' car pour un daltonien la couleur c'est un facteur discriminant....

Tu trouves que je suis rigide et fermé prouves moi que j'ai tord en m'indiquant un moyen même très imaginatif pour faire une comparaison d'égalité entre une voiture et une pomme qui tienne un minimum la route (au sens OO s'entend ), et je reverrai ma position

Au sens OO ???? Ce qui nous intéresse (en tout cas moi) c'est le sens de l'égalité dans un domaine/métiers.

Oui je te trouve rigide et fermé car tu n'arrives mêmes pas à accepter le fait que l'on puisse comparer des voitures et des véhicules ou des voitures et des camions ou des voitures et des vélos alors que sur bien des points ils sont comparables ne serait-ce que d'un point de vue énergétique.

De plus la super classe object est totalement justifiée, c'est un choix de conception qui apporte des avantages et des inconvénients certainement à l'instar de l'héritage multiple.

[kisitomomotene]

Au sens OO ???? Ce qui nous intéresse (en tout cas moi) c'est le sens de l'égalité dans un domaine/métiers.

Vous avez en parti raison. Le problème est qu'il faut d'abord se mettre d'accord sur la définition de l'égalité.
En Mathématiques un objet n'est égal qu'à lui même, et vérifier si deux variables sont égales revient à vérifier si les deux variables désignent le même objet. Vu sous cet aspect stricte deux voitures ne peuvent jamais être égales même si elles ont la même marque, même couleurs, même numéro de châssis etc.
Mais les mathématiques définissent une notion d’égalité beaucoup plus large qui est l'équivalence. Et je crois que l'opérateur d'égalité dans beaucoup de langages de programmation correspond plutôt à la notion d'équivalence mathématique. Vu sous cet aspect d'équivalence un chien peut même être égale à un caillou, tout dépend alors de la relation d'équivalence qu'on aura définie au préalable!

[koala01]

Vous avez en parti raison. Le problème est qu'il faut d'abord se mettre d'accord sur la définition de l'égalité.
En Mathématiques un objet n'est égal qu'à lui même, et vérifier si deux variables sont égales revient à vérifier si les deux variables désignent le même objet. Vu sous cet aspect stricte deux voitures ne peuvent jamais être égales même si elles ont la même marque, même couleurs, même numéro de châssis etc.
Mais les mathématiques définissent une notion d’égalité beaucoup plus large qui est l'équivalence. Et je crois que l'opérateur d'égalité dans beaucoup de langages de programmation correspond plutôt à la notion d'équivalence mathématique. Vu sous cet aspect d'équivalence un chien peut même être égale à un caillou, tout dépend alors de la relation d'équivalence qu'on aura définie au préalable!

Je ne suis pas d'accord!!!

Pour les classe ayant sémantique de valeur (la classe string par exemple), il n'y a pas de problème, car "Bonjour" sera "Bonjour" et l'on peut pousser jusqu'à dire que "Bonjour" est équivalent à "Hello".

Pour les classes ayant sémantique d'entité, l'égalité est beaucoup plus difficile à obtenir, vu qu'il n'y aura jamais que la l'objet considéré qui pourra être égal à lui-même.

Maiis pour ce qui en est de l'équivalence, il faut au minimum que les deux objets aient des caractèrestique identiques !

Si l'on admet que equals teste l'équivalence, il n'y a qu'une voiture verte de 300000 km, diesel, de marque UnTel qui sera équivalent à une autre voiture verte de 300000 km, diesel, de marque UnTel!

Tenter de comparer une telle voiture ne serait-ce qu'à un camion (qui dispose des caractéristiques identique) n'est pas envisageable car, dans les caractéristiques des deux véhicule, il y a la notion de poids et que le fait d'essayer de créer un camion du poids d'une voiture (ou une voiture du poids d'un camion) aura violé l'invariant qui dit que le poids d'un camion est supérieur à 3.5 T ou celui qui dit que le poids d'une voiture est inférieur à 3.5T !!!

Là, ca "aurait" pu marcher, mais, comparer une voiture avec un vélo (qui est pourtant aussi un véhicule!!!) n'a déjà que beaucoup moins de sens parce qu'on ne dispose plus de caractéristiques comparables et, plus on va s'éloigner de la hiérarchie "véhicule", plus il sera impossible de de vérifier l'équivalence entre une voiture et un autre objet!

[kisitomomotene]

Je ne suis pas d'accord!!!

Pour les classe ayant sémantique de valeur (la classe string par exemple), il n'y a pas de problème, car "Bonjour" sera "Bonjour" et l'on peut pousser jusqu'à dire que "Bonjour" est équivalent à "Hello".

Pour les classes ayant sémantique d'entité, l'égalité est beaucoup plus difficile à obtenir, vu qu'il n'y aura jamais que la l'objet considéré qui pourra être égal à lui-même.

Maiis pour ce qui en est de l'équivalence, il faut au minimum que les deux objets aient des caractèrestique identiques !
!

Il ne s'agit pas d'avoir une opinion, être d'accord ou ne pas être d'accord. Je parle moi de réalité d'un point de vue mathématiques, et ce que vous devriez faire c'est de revoir ces notions mathématiques. Il n' y a pas d'opinion en mathématiques!

[Luc Hermitte]

Il y a des trucs immuables en mathématiques et les entités manipulées sont tout sont immuables (cf le débat sur le LSP carrés & rectangle).

De vouloir ressortir la théorie mathématique ici n'apporte pas grand chose car la dichotomie entité/valeur tient aussi en grande partie à cette notion de comportement qui n'existe pas en maths.

[kisitomomotene]

Il y a des trucs immuables en mathématiques et les entités manipulées sont tout sont immuables (cf le débat sur le LSP carrés & rectangle).

De vouloir ressortir la théorie mathématique ici n'apporte pas grand chose car la dichotomie entité/valeur tient aussi en grande partie à cette notion de comportement qui n'existe pas en maths.

Le problème c'est qu'on a une notion mathématique qui modélise une opération informatique (dans notre cas l'opérateur d'égalité) et vise versa c'est à dire l'opérateur d'égalité peut être utilisé pour résoudre un problème mathématique sur les classes d'équivalence.

Donc il est impératif de bien comprendre le modèle mathématique pour savoir comment conduire l'implémentation informatique.

Et savoir si on peut dire qu'un Chien est égal à un caillou ou non, est d'abord un problème "métier" avant d'être un problème informatique. Et si le métier ce sont les mathématiques, on peut bien dire qu'un chien est égal (dans le sens d'une relation d'équivalence) à un caillou, tout dépendant de la relation d'équivalence définie

[jabbounet]

ceci dit pour compléter le problème qui dit opérateur d'égalité "==" ou "!=" dit aussi comparaison de type ">" ">=" < et "<=" comment ordoner un pomme, un vélo et un camion et de la choucroute...

[souviron34]

ceci dit pour compléter le problème qui dit opérateur d'égalité "==" ou "!=" dit aussi comparaison de type ">" ">=" < et "<=" comment ordoner un pomme, un vélo et un camion et de la choucroute...

ça dépend de la faim et du contexte

Certains mangent des avions ou des camions (voir certains concours Guiness)

[kisitomomotene]

ceci dit pour compléter le problème qui dit opérateur d'égalité "==" ou "!=" dit aussi comparaison de type ">" ">=" < et "<=" comment ordoner un pomme, un vélo et un camion et de la choucroute...

Non c'est faux. Et si précisément en Java on a doté la classe Object de l'opérateur equal et pas des opérateurs gt (>), lt (<) etc c'est justement parce que un ensemble peut être doté d'une relation d’équivalence et pas d'une relation d'ordre. Un peu comme si quelqu'un dit que si on définit l'opération + alors il y aura forcement les opérations * et /.

[jabbounet]

Non c'est faux. Et si précisément en Java on a doté la classe Object de l'opérateur equal et pas des opérateurs gt (>), lt (<) etc c'est justement parce que un ensemble peut être doté d'une relation d’équivalence et pas d'une relation d'ordre. Un peu comme si quelqu'un dit que si on définit l'opération + alors il y aura forcement les opérations * et /.

ok il n'y a pas de relation d'ordre sur object, il n’empêche que l'on peut y penser quand on commence a vouloir comparer des objets.

Cependant je viens de revoir l'api d'object et je me demande pourquoi si object est censé représenter l'objet minimal de tous les objet java lui adjoindre des notions lié à la programmation multithreadé.

Je pense aux wait/notify, en effet toutes les applis java n'ont pas nécessairement besoin de se multithreader (genre une appli bebete qui parse un fichier de log pour extraire des message d'erreur particulier).

[adiGuba]

Cependant je viens de revoir l'api d'object et je me demande pourquoi si object est censé représenter l'objet minimal de tous les objet java lui adjoindre des notions lié à la programmation multithreadé.

Je pense aux wait/notify, en effet toutes les applis java n'ont pas nécessairement besoin de se multithreader (genre une appli bebete qui parse un fichier de log pour extraire des message d'erreur particulier).

C'est une erreur que l'on se traine comme un boulet...

Cela vient du fait qu'ils voulaient que tout objet puisse servir de verrou, mais ces méthode n'ont vraiment rien à faire là. Il aurait fallut les intégrer dans une API distincte.


a++

[koala01]

Donc il est impératif de bien comprendre le modèle mathématique pour savoir comment conduire l'implémentation informatique.

Et savoir si on peut dire qu'un Chien est égal à un caillou ou non, est d'abord un problème "métier" avant d'être un problème informatique. Et si le métier ce sont les mathématiques, on peut bien dire qu'un chien est égal (dans le sens d'une relation d'équivalence) à un caillou, tout dépendant de la relation d'équivalence définie

Mais, même si du point de vue de l'aspect métier pour lequel l'application est envisagée, il est possible d'envisager une équivalence (et encore : à ce moment là, le nom de la fonction n'aurait pas du être equals ) entre un chien et un caillou, c'est qu'il faut des points de comparaison!

Il est en effet impossible de déterminer si une variable est équivalente à une autre si l'on ne compare rien, tu sera d'accord, non

Or, le problème, c'est que si on fait chien.equals(cailloux) cailloux n'est pas vu, à l'intérieur de la fonction comme une instance de type Caillou, mais bel et bien comme une instance de type... Object!

On est donc, a priori, l'imité à l'interface de Object, qui a peu de chance de fournir ce qui sera nécessaire pour obtenir le point de comparaison!!!

Bien sur, il y a toujours la solution du transtypage, mais:

1. Soit vous transtyperez "à la rache" votre Object en cailloux, en priant que ce soit bien un cailloux et pas autre chose
2. Soit vous devrez commencer par vérifier le type reel de votre Object, et là...

Ben, là, il faut espérer que vous ne voudrez pas envisager l'équivalence entre un Chien et trop de types différents, parce que les possibilités qui vous sont offertes sont :

• redéfinir 50 fois votre fonction equals en fournissant chaque fois un type différent en argument
• utiliser un visiteur, ce qui revient au même
• travailler avec un pattern "Chain Of Responsability" qui, AMA est quand meme un peu lourd quand il s'agit simplement de permettre à une fonction de comparaison de fonctionner

Qu'à la limite, on puisse considérer comme possible de trouver une équivalence entre une voiture, un camion et un vélo, soit... Il y a de fores chances pour que tous ces types héritent de vehicule

Mais quand il s'agira de comparer ces mêmes voitures, vélos ou camions à des chiens, des chats ou des cailloux, il faudra remonter vraiment haut dans la hiérarchie de classes pour trouver un type de base commun (la pire des possibilités étant de devoir remonter au niveau de Object )

Or, plus on remonte dans la hiérarchie de classes, plus on perd de possibilités de trouver un point de comparaison sans recourir à un transtypage!!!

De plus la super classe object est totalement justifiée, c'est un choix de conception qui apporte des avantages et des inconvénients certainement à l'instar de l'héritage multiple.

A ceci près que tu restes libre de recourir à l'héritage multiple alors que l'héritage de la super classe objet est implicite!

On te laisses donc le choix d'utiliser (ou non) l'héritage multiple si tu te sens de taille à affronter les problèmes qu'il peut poser

De plus, je n'ai jamais dit que le recours à la super classe object n'était pas justifié, et j'admets une grande part des justifications qui pourront être données (ne les connaissant pas toutes, je me réserve juste le droit de n'être peut être pas d'accord avec toutes ).

Mais il n'empêche que, conceptuellement parlant, c'est un choix de conception horrible et dangereux (ou à tout le moins discutable) car il crée des relations forcées là où, a priori, il n'y a peut etre pas lieu d'en avoir (ne serait-ce que le fait de permettre qu'un caillou et qu'un véhicule puisse se retrouver dans une même collection d'objets, ou celui d'en arriver à admettre qu'il soit possible de trouver une relation d'équivalence entre l'un et l'autre, même si je suis convaincu que nous ne devrions pas parler d'équivalence mais bel et bien d'égalité au sujet de la fonction equals).

[kisitomomotene]

Mais, même si du point de vue de l'aspect métier pour lequel l'application est envisagée, il est possible d'envisager une équivalence (et encore : à ce moment là, le nom de la fonction n'aurait pas du être equals ) entre un chien et un caillou, c'est qu'il faut des points de comparaison!

Il est en effet impossible de déterminer si une variable est équivalente à une autre si l'on ne compare rien, tu sera d'accord, non
Or, le problème, c'est que si on fait chien.equals(cailloux) cailloux n'est pas vu, à l'intérieur de la fonction comme une instance de type Caillou, mais bel et bien comme une instance de type... Object!

On est donc, a priori, l'imité à l'interface de Object, qui a peu de chance de fournir ce qui sera nécessaire pour obtenir le point de comparaison!!!

Bien sur, il y a toujours la solution du transtypage, mais:
Soit vous transtyperez "à la rache" votre Object en cailloux, en priant que ce soit bien un cailloux et pas autre chose
Soit vous devrez commencer par vérifier le type reel de votre Object, et là...
Ben, là, il faut espérer que vous ne voudrez pas envisager l'équivalence entre un Chien et trop de types différents, parce que les possibilités qui vous sont offertes sont :
redéfinir 50 fois votre fonction equals en fournissant chaque fois un type différent en argument
utiliser un visiteur, ce qui revient au même
travailler avec un pattern "Chain Of Responsability" qui, AMA est quand meme un peu lourd quand il s'agit simplement de permettre à une fonction de comparaison de fonctionner

Qu'à la limite, on puisse considérer comme possible de trouver une équivalence entre une voiture, un camion et un vélo, soit... Il y a de fores chances pour que tous ces types héritent de vehicule
.

Les critères d'une comparaison sont purement ARBITRAIRES, le problème c'est que vous vous limitez à votre expérience personnelle de type de problème que avez eu à résoudre ou que vous imaginez possible de résoudre. Je peux décider qu'une voiture est égale à un cailloux si le poids du véhicule dépasse 100kg et celui du caillou inférieur à 5kg. Si dans votre expérience propre de la résolution des problèmes cela n'a aucun sens là n'est pas le problème. Le problème est que une foi admis cette règle comment par exemple écrire un programme qui va comparer une voiture et un cailloux donné et afficher vert s'il y a égalité et rouge sinon. C'est tout, je peux demander à mes élèves de 6eme d'écrire ce petit programme pour leur faire assimiler la notion de classe d’équivalence ( si j'estime qu'effectivement cela peut les aider) et dans cette perspective ils ne sont pas obligé de redéfinir 50 fois la fonction equal ( deux fois tout au plus), ni d'utiliser les visiteurs.

voiture, vélo, camion ont une même classe mère véhicule si mon application modélise le monde "réel" que j'observe. Mais rien ne m'empêche de définir une théorie ( dans son sens mathématique) ou une voiture et un vélo n'ont aucun point en commun!

[koala01]

Les critères d'une comparaison sont purement ARBITRAIRES, le problème c'est que vous vous limitez à votre expérience personnelle de type de problème que avez eu à résoudre ou que vous imaginez possible de résoudre. Je peux décider qu'une voiture est égale à un cailloux si le poids du véhicule dépasse 100kg et celui du caillou inférieur à 5kg. Si dans votre expérience propre de la résolution des problèmes cela n'a aucun sens là n'est pas le problème. Le problème est que une foi admis cette règle comment par exemple écrire un programme qui va comparer une voiture et un cailloux donné et afficher vert s'il y a égalité et rouge sinon.

Sauf que, pour pouvoir comparer le poids de la voiture et celui du cailloux, il faut que tu aies accès à ce poids...

Or, la classe Object (qui est le type sous lequel tu connais le cailloux dans la fonction equals), tu ne disposes pas de cette information sans passer par le transtypage!

Alors, comme je l'ai indiqué plus haut, tu as soit le choix entre transtyper "à la rache" ton object en cailloux (en espérant que ce ne soit pas un chien en réalité), soit tu peux "blinder" le transtypage (entre autre en passant par la fonction isInstanceOf ou autre).

Mais, encore une fois, il faut espérer que tu ne souhaiteras pas envisager ce genre d'équivalence avec trop de types, car, autrement, ton code va rapidement ingérable!

Et je ne parle même pas des problèmes que tu risque de rencontrer lorsque tu voudras rajouter un type à ta notion d'équivalence!

C'est tout, je peux demander à mes élèves de 6eme d'écrire ce petit programme pour leur faire assimiler la notion de classe d’équivalence ( si j'estime qu'effectivement cela peut les aider) et dans cette perspective ils ne sont pas obligé de redéfinir 50 fois la fonction equal ( deux fois tout au plus), ni d'utiliser les visiteurs.

Tant que tu te limites à deux types, tu pourras faire quelque chose de "simple", en effet...

Mais n'as tu jamais appris que, dans la vie réelle, les besoins évoluent en permanence

voiture, vélo, camion ont une même classe mère véhicule si mon application modélise le monde "réel" que j'observe. Mais rien ne m'empêche de définir une théorie ( dans son sens mathématique) ou une voiture et un vélo n'ont aucun point en commun!

Je vais même aller plus loin, parce que cela va exactement dans le sens de ce que je veux expliquer:

Je n'ai strictement aucune objection, dans un domaine particulier dans lequel cela pourrait s'avérer nécessaire, à trouver un camion et un cailloux dans la même hiérarchie de classes... A condition que cela vienne d'un choix fait en connaissance de cause!

Par contre, avoir à "subir" une relation qui n'est pas souhaitée (parce que, dans un autre domaine, cailloux, camions, voiture et vélos n'ont aucun besoin d'avoir une quelconque relation ) est un symptome de problème de conception