| Accueil de l'archive | Service proposé par Hervé AGNOUX |
Date sent: Tue, 23 Jan 2001 16:16:06 +0100 (CET) From: clauzel marc <mclauzel@yahoo.fr> Subject: Appellation To: java java <java@u-strasbg.fr> Send reply to: java@u-strasbg.fr Salut la liste! J'aurais voulu savoir ce que l'on appelait une méthode virtuelle. Qu'elles autres types existe t'il? Qu'elles sont leurs spécificités en terme de coût (place, temps....) Merci par avance A+ ___________________________________________________________ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com
Date sent: Tue, 23 Jan 2001 16:44:01 +0100
From: "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr>
Organization: CS-Institut ( http://www.csinstitut.fr )
To: java@u-strasbg.fr
Subject: Re: Appellation
Send reply to: java@u-strasbg.fr
Salut !
clauzel marc a écrit :
> J'aurais voulu savoir ce que l'on appelait une méthode virtuelle.
> Qu'elles autres types existe t'il? Qu'elles
> sont leurs spécificités en terme de coût (place, temps....)
Sauf erreur une méthode virtuelle typique en C++ (correction les autres si
je me gourre, moi c'est comme ça que je le vois) c'est une classe
abstraite pour faire de la délégation au lieu de l'héritage, typiquement
pour nous en Java une interface. Donc la méthode virtuelle/abstraite de la
classe mère aura bien un nom mais n'aura aucun code (pas le droit), alors
que les classes qui en héritent devront implémenter ce code (obligation)
même si c'est du code vide ( {} ). C'est pas une question de coût (place,
temps....) ou autre, c'est exclusivement une question d'architecture si on
utilise plutôt la délégation que l'héritage. Exemple la classe Oiseau avec
la méthode voler(), qui marche très bien jusqu'au jour où tu dois
classifier le pingouin qui ne vole pas, là tu l'as dans l'os profond
puisque c'est bien un genre d'oiseau mais qui te sabote ta classification
si tu fais de l'héritage puisque la méthode voler devrait exister pour
tous les piafs sauf pour lui. Alors tu fais plutôt de la délégation en
créant l'interface VoleAutantQunHommePolitique qui comprend la
fonctionnalité apportée par la méthode "voler()", méthode qu'évidemment tu
retires de la classe générale Oiseau, et là tout baigne : les piafs qui
volent héritent de Oiseau et implémentent l'interface
VoleAutantQunHommePolitique, alors que le pingouin hérite aussi de Oiseau
mais n'implémente pas cette interface, donc le pingouin est bien un Oiseau
qui ne vole pas.
@ ++ !
--
^
° ° Eric LEMAITRE
/ V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS)
// \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX
Certified)
/ ( ) \ Responsable de formation pour les filières Internet et Linux
(Head of Internet/Linux Education Department)
^~^
Date sent: Tue, 23 Jan 2001 17:00:45 +0100 To: java@u-strasbg.fr From: Guillaume Perréal <perreal@lyon.cemagref.fr> Subject: Re: Appellation Send reply to: java@u-strasbg.fr At 16:44 23/01/01 +0100, you wrote: Salut ! clauzel marc a écrit : > J'aurais voulu savoir ce que l'on appelait une méthode virtuelle. > Qu'elles autres types existe t'il? Qu'elles > sont leurs spécificités en terme de coût (place, temps....) Sauf erreur une méthode virtuelle typique en C++ (correction les autres si je me gourre, moi c'est comme ça que je le vois) c'est une classe abstraite pour faire de la délégation au lieu de l'héritage, typiquement pour nous en Java une interface. Tu devrais te relire : "une méthode [...] c'est une classe" !?! Voilà ce que je me souviens de 'virtuel' et 'abstrait' en C++ : - une méthode virtuelle d'une classe A est une méthode qui peut-être redéfinie par une sous-classe de A. En C++, on peut en effet définir des méthodes qui ne pourront pas être redéfinies par les sous-classes. - une méthode abstraite est une méthode virtuelle qui doit être redéfinie; pour la déclarer, on utilise le mot clef 'abstract' à la place du corps de la fonction. Notez qu'une classe qui a au moins une méthode abstraite ne peut pas être instanciée (parce qu'il y a une méthode dont le comportement est indéfini). - une classe abstraite est une classe qui n'a que des méthodes abstraites. - une classe virtuelle, ça n'existe pas car cela n'aurait pas de sens : "une classe qui peut être redéfinie par ses sous-classes". En Java, toutes les méthodes sont virtuelles (me semble-t-il), et les interfaces correspondent à peu près aux classes abstraites. Rappelons également qu'en C++, le conception d'interface n'existe pas, et une classe peut hériter simultanément de plusieurs classes, d'où l'utilisation de classes abstraites. Alors qu'en Java, une classe ne peut hériter que d'une seule classe, mais elle peut implémenter plusieurs interfaces. @+ Guillaume Perréal Cemagref - Unité de recherche hydrologie-hydraulique 3 Bis Quai Chauveau - CP 220 - 69336 LYON Cedex 09 - FRANCE Tél. +33 (0) 4 72 20 87 69 FAX : +33 (0) 4 78 47 78 75
Date sent: Tue, 23 Jan 2001 17:17:17 +0100 (CET)
From: clauzel marc <mclauzel@yahoo.fr>
Subject: Re: Appellation
To: java@u-strasbg.fr
Send reply to: java@u-strasbg.fr
impec, merci, bien aimé le coup du pingouin... :))
--- Eric LEMAITRE <eric.lemaitre@csinstitut.fr> a
écrit : > Salut !
>
> clauzel marc a écrit :
>
> > J'aurais voulu savoir ce que l'on appelait une
> méthode virtuelle.
> > Qu'elles autres types existe t'il? Qu'elles
> > sont leurs spécificités en terme de coût (place,
> temps....)
>
> Sauf erreur une méthode virtuelle typique en C++
> (correction les autres
> si je me gourre, moi c'est comme ça que je le vois)
> c'est une classe
> abstraite pour faire de la délégation au lieu de
> l'héritage, typiquement
> pour nous en Java une interface.
> Donc la méthode virtuelle/abstraite de la classe
> mère aura bien un nom
> mais n'aura aucun code (pas le droit), alors que les
> classes qui en
> héritent devront implémenter ce code (obligation)
> même si c'est du code
> vide ( {} ).
> C'est pas une question de coût (place, temps....) ou
> autre, c'est
> exclusivement une question d'architecture si on
> utilise plutôt la
> délégation que l'héritage.
> Exemple la classe Oiseau avec la méthode voler(),
> qui marche très bien
> jusqu'au jour où tu dois classifier le pingouin qui
> ne vole pas, là tu
> l'as dans l'os profond puisque c'est bien un genre
> d'oiseau mais qui te
> sabote ta classification si tu fais de l'héritage
> puisque la méthode
> voler devrait exister pour tous les piafs sauf pour
> lui. Alors tu fais
> plutôt de la délégation en créant l'interface
> VoleAutantQunHommePolitique qui comprend la
> fonctionnalité apportée par
> la méthode "voler()", méthode qu'évidemment tu
> retires de la classe
> générale Oiseau, et là tout baigne : les piafs qui
> volent héritent de
> Oiseau et implémentent l'interface
> VoleAutantQunHommePolitique, alors
> que le pingouin hérite aussi de Oiseau mais
> n'implémente pas cette
> interface, donc le pingouin est bien un Oiseau qui
> ne vole pas.
>
> @ ++ !
>
> --
> ^
> ° ° Eric LEMAITRE
> / V \ Ingénieur CNAM (CNAM Computer Engineer,
> MSCS)
> // \\ Ingénieur et Formateur certifié Linux
> Red-Hat (RHCE & RHCX
> Certified)
> / ( ) \ Responsable de formation pour les filières
> Internet et Linux
> (Head of Internet/Linux Education Department)
> ^~^
>
>
___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
From: "Cedric Beust" <cedric@beust.com>
To: <java@u-strasbg.fr>
Subject: RE: Appellation
Date sent: Tue, 23 Jan 2001 10:53:40 -0800
Send reply to: java@u-strasbg.fr
> From: Eric LEMAITRE [mailto:eric.lemaitre@csinstitut.fr]
> Sauf erreur une méthode virtuelle typique en C++ (correction les autres
> si je me gourre, moi c'est comme ça que je le vois) c'est une classe
> abstraite pour faire de la délégation au lieu de l'héritage, typiquement
> pour nous en Java une interface.
Ouh la, une methode virtuelle est une class abstraite ?!?
Le mot-cle virtuel vient de C++, langage dans lequel les fonctions-membres
(methodes) ne sont pas polymorphiques par defaut. Les methodes Java sont
virtuelles par defaut (elles ne le sont plus si on specifie "final').
Par exemple :
class A {
public void foo() { System.out.println("A.foo"); }
}
class B extends A {
public void foo() { System.out.println("B.foo"); }
}
A a = new B();
a.foo();
affichera "B.foo()".
Le code equivalent en C++ aurait affiche "A.foo()", sauf si le mot-cle
"virtual" est present devant la definition de A::foo().
> VoleAutantQunHommePolitique qui comprend la fonctionnalité apportée par
> la méthode "voler()", méthode qu'évidemment tu retires de la classe
> générale Oiseau, et là tout baigne : les piafs qui volent héritent de
> Oiseau et implémentent l'interface VoleAutantQunHommePolitique, alors
> que le pingouin hérite aussi de Oiseau mais n'implémente pas cette
> interface, donc le pingouin est bien un Oiseau qui ne vole pas.
Wow.
--
Cedric
To: java@u-strasbg.fr Subject: Re: Appellation From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 24 Jan 2001 12:13:40 +0100 Send reply to: java@u-strasbg.fr "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr> writes: > > Interface VoleAutantQunHommePolitique qui comprend la fonctionnalité > > apportée par la méthode "voler()", méthode qu'évidemment tu retires de > > la classe générale Oiseau, et là tout baigne : les piafs qui volent > > héritent de Oiseau et implémentent l'interface > > VoleAutantQunHommePolitique, alors que le pingouin hérite aussi de > > Oiseau mais n'implémente pas cette interface, donc le pingouin est > > bien un Oiseau qui ne vole pas. Wow. > "Wow", mais encore ? Je ne dis pas que la tentative d'humour est de bon > goût, mais en tout cas pas d'erreur flagrante sur cet exemple :-)) ? Dans ce type de cas qui correspond à une relation d'héritage non-monotone, je pense que ce serait dommage de retirer la méthode "vole()" de la classe générale Oiseau, parce que typiquement elle va être utilisée par la très grande majorité des classes filles. J'aurais plutôt utilisé un pattern style "Marker Interface" : la fonctionnalité est offerte par la classe de base, mais on utilise une interface comme marqueur pour rendre la fonctionnalité disponible. Donc, un vole() dans Oiseau, qui renvoie une exception NeVolePas si l'interface-marqueur QuiVole n'est pas explicitement déclarée comme implémentée dans la définition de la classe. -- Rodrigo
Date sent: Wed, 24 Jan 2001 13:09:20 +0100
From: "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr>
Organization: CS-Institut ( http://www.csinstitut.fr )
To: java@u-strasbg.fr
Subject: Re: Appellation
Send reply to: java@u-strasbg.fr
Salut !
Rodrigo Reyes a écrit :
> Dans ce type de cas qui correspond à une relation d'héritage
> non-monotone, je pense
> que ce serait dommage de retirer la méthode "vole()" de la classe
> générale Oiseau, parce que typiquement elle va être utilisée par la
> très grande majorité des classes filles.
Tu as tout à fait raison, c'est bien tout le problème : les Oiseaux en
général volent à 99%, seules quelques exceptions du genre pingouin ne
volent pas alors qu'ils sont bien du genre Oiseau, il faudrait donc bien
logiquement implémenter la méthode voler() dans la classe Oiseau mais si
le pingouin hérite d'Oiseau alors il vole, problème... J'ai bien poposé
l'interface ajoutant la méthode voler() qui apporte une solution
conceptuelle très propre au problème (en toute modestie je pense) mais pas
logique du tout puisque tout nouvel Oiseau devra implémenter cette méthode
supplémentaire "extraordinaire" qu'ils possèdent en natif dans 99% des
cas. C'est pas top au point de vue logique, mais je ne vois pas comment
faire "simple" autrement.
> J'aurais plutôt utilisé un pattern style "Marker Interface" : la
> fonctionnalité est
> offerte par la classe de base, mais on utilise une interface comme
> marqueur pour rendre la fonctionnalité disponible. Donc, un vole() dans
> Oiseau, qui renvoie une exception NeVolePas si l'interface-marqueur
> QuiVole n'est pas explicitement déclarée comme implémentée dans la
> définition de la classe.
Là je voudrais que tu nous en dise plus, car celui là je ne connais pas du
tout, je n'ai que de bonnes notions de Design Patterns. Mais pourquoi pas
un simple Factory Pattern avec un appel du genre "nouvelEmplumé(booléen)",
le booléen étant à true s'il vole (l'Oiseau en général) et false sinon (le
pingouin), la Factory pouvant vraiment nous retourner une instance de
classe où il y a ou pas la méthode voler() de définie selon le cas ?
@ ++ !
--
^
° ° Eric LEMAITRE
/ V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS)
// \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX
Certified)
/ ( ) \ Responsable de formation pour les filières Internet et Linux
(Head of Internet/Linux Education Department)
^~^
From: ROUSSEL Yohann <yohann.roussel@criltelecom.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: Appellation Date sent: Wed, 24 Jan 2001 13:11:33 +0100 Send reply to: java@u-strasbg.fr > -----Message d'origine----- > De: Eric LEMAITRE [SMTP:eric.lemaitre@csinstitut.fr] > Date: mercredi 24 janvier 2001 13:09 > À: java@u-strasbg.fr > Objet: Re: Appellation > > Salut ! > > Rodrigo Reyes a écrit : > > > Dans ce type de cas qui correspond à une relation d'héritage > non-monotone, je pense > > que ce serait dommage de retirer la méthode "vole()" de la classe > générale Oiseau, > > parce que typiquement elle va être utilisée par la très grande > > majorité > des classes > > filles. > > Tu as tout à fait raison, c'est bien tout le problème : les Oiseaux en > général volent à 99%, seules quelques exceptions du genre pingouin ne > volent pas alors qu'ils sont bien du genre Oiseau, il faudrait donc bien > logiquement implémenter la méthode voler() dans la classe Oiseau mais si > le pingouin hérite d'Oiseau alors il vole, problème... J'ai bien poposé > l'interface ajoutant la méthode voler() qui apporte une solution > conceptuelle très propre au problème (en toute modestie je pense) mais > pas logique du tout puisque tout nouvel Oiseau devra implémenter cette > méthode supplémentaire "extraordinaire" qu'ils possèdent en natif dans > 99% des cas. C'est pas top au point de vue logique, mais je ne vois pas > comment faire "simple" autrement. > > > J'aurais plutôt utilisé un pattern style "Marker Interface" : la > fonctionnalité est > > offerte par la classe de base, mais on utilise une interface comme > marqueur pour rendre > > la fonctionnalité disponible. Donc, un vole() dans Oiseau, qui > > renvoie > une exception > > NeVolePas si l'interface-marqueur QuiVole n'est pas explicitement > déclarée comme > > implémentée dans la définition de la classe. > c'est le principe de la serialisation d'Obect et de l'interface serializable non ? > Là je voudrais que tu nous en dise plus, car celui là je ne connais pas > du tout, je n'ai que de bonnes notions de Design Patterns. Mais pourquoi > pas un simple Factory Pattern avec un appel du genre > "nouvelEmplumé(booléen)", le booléen étant à true s'il vole (l'Oiseau en > général) et false sinon (le pingouin), la Factory pouvant vraiment nous > retourner une instance de classe où il y a ou pas la méthode voler() de > définie selon le cas ? > > @ ++ ! > > -- > ^ > ° ° Eric LEMAITRE > / V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS) > // \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX > Certified) > / ( ) \ Responsable de formation pour les filières Internet et Linux > (Head of Internet/Linux Education Department) > ^~^ >
From: "Thibaut Fagart" <tfagart@soleri.com> To: <java@u-strasbg.fr> Subject: RE: Appellation Date sent: Wed, 24 Jan 2001 13:33:09 +0100 Send reply to: java@u-strasbg.fr Comme la plupart des problemes de ce genre (Classe oiseau et aptitude a voler), le probleme réside dans une mauvaise connaissance du " metier ". Pour nous, un oiseau vole, mais pour le dictionnaire, voici la definition d'un oiseau : oiseau n. m. 1. Vertébré ovipare, couvert de plumes, ayant deux pattes et deux ailes, à la tête munie d'un bec et généralement adapté au vol. On trouve un additif " encyclopédie " dont voici le contenu Comme les mammifères, les oiseaux sont homéothermes et leur coeur comporte quatre cavités. Ils sont apparus au jurassique dans une lignée de reptiles qui a donné également les dinosaures et les crocodiliens. Deux sous-classes sont représentées actuellement: les ratites, sans bréchet et inaptes au vol, et les carinates, dont le bréchet supporte les muscles nécessaires au vol. La solution est donc de faire une classe Mere, abstraite, Oiseau dont l'interface ne présente pas la méthode " voler " et deux sous classes Ratite (toujours sans " voler ") et Carinate qui elle presente cette méthode ... Si l'on revient on fond de la question, théoriquement, une sous classe hérite de la TOTALITE des comportements de sa super classe... -----Message d'origine----- De : Eric LEMAITRE [mailto:eric.lemaitre@csinstitut.fr] Envoyé : mercredi 24 janvier 2001 13:09 À : java@u-strasbg.fr Objet : Re: Appellation Salut ! Rodrigo Reyes a écrit : > Dans ce type de cas qui correspond à une relation d'héritage non-monotone, je pense > que ce serait dommage de retirer la méthode "vole()" de la classe générale Oiseau, > parce que typiquement elle va être utilisée par la très grande majorité des classes > filles. Tu as tout à fait raison, c'est bien tout le problème : les Oiseaux en général volent à 99%, seules quelques exceptions du genre pingouin ne volent pas alors qu'ils sont bien du genre Oiseau, il faudrait donc bien logiquement implémenter la méthode voler() dans la classe Oiseau mais si le pingouin hérite d'Oiseau alors il vole, problème... J'ai bien poposé l'interface ajoutant la méthode voler() qui apporte une solution conceptuelle très propre au problème (en toute modestie je pense) mais pas logique du tout puisque tout nouvel Oiseau devra implémenter cette méthode supplémentaire "extraordinaire" qu'ils possèdent en natif dans 99% des cas. C'est pas top au point de vue logique, mais je ne vois pas comment faire "simple" autrement. Thibaut Fagart Expart et Architecte Java, Analyste UML Soleri Ima
Date sent: Wed, 24 Jan 2001 14:00:26 +0100
From: "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr>
Organization: CS-Institut ( http://www.csinstitut.fr )
To: java@u-strasbg.fr
Subject: Re: Appellation
Send reply to: java@u-strasbg.fr
Salut !
Thibaut Fagart a écrit :
> Comme la plupart des problemes de ce genre (Classe oiseau et aptitude a
> voler), le probleme réside dans une mauvaise connaissance du " metier ".
C'est vrai au fond, c'est tout le problème de faire du "vrai orienté
objet" donc de la réutilisation, le problème qui tue c'est qu'il faut
avoir d'avance une idée des développements qu'on va nous demander pour
faire des classes vraiment génériques dès le départ. Un consultant avait
fait une remarque de la mort de ce style dans 01-Informatique (désolé pour
la pub) du genre "les objets c'est déjà un concept de pointe dépassé et
ringard, la mode actuelle du top techno (de l'époque) c'est le push
applicatif... Le problème c'est que 99% de mes clients n'en sont même pas
encore à l'orienté objets" (du genre des gens qui croyaient faire de
l'orienté objets parcequ'ils utilisaient Visual C++ alors qu'ils
l'utilisaient pour programmer en C ordinaire).
> Pour nous, un oiseau vole, mais pour le dictionnaire, voici la
> definition d'un oiseau : oiseau n. m. 1. Vertébré ovipare, .............
> Deux sous-classes sont représentées actuellement: les ratites, sans
> bréchet et inaptes au vol, et les carinates, dont le bréchet supporte
> les muscles nécessaires au vol.
Ah t'ain... déjà qu'on a parfois du mal à causer couramment interface,
héritage, délégation, instance,... et tout le toutim, maintenant en plus
faut connaître par coeur le dictionnaire pour modéliser... J'avais
remarqué que vu certains des problèmes qu'on se pose sur cette liste, il y
a des moments où on comprend mieux de quoi on cause si on a fait philo
qu'informatique... Bon OK, en plus de la certif Java je me programme une
certif philo et je me réinsère dans la liste :-)) ... @ ++ !
> La solution est donc de faire une classe Mere, abstraite, Oiseau dont
> l'interface ne présente pas la méthode " voler " et deux sous classes
> Ratite (toujours sans " voler ") et Carinate qui elle presente cette
> méthode ...
C'est très exactement la solution idéale, je pense que ça répond
exactement et sans détours à la question posée au départ.
> Si l'on revient on fond de la question, théoriquement, une sous classe
> hérite de la TOTALITE des comportements de sa super classe...
Exact, dans l'idéal de rêve c'est ce qu'il faudrait tenter de réaliser...
Si on peut.
@ ++ !
--
^
° ° Eric LEMAITRE
/ V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS)
// \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX
Certified)
/ ( ) \ Responsable de formation pour les filières Internet et Linux
(Head of Internet/Linux Education Department)
^~^
To: java@u-strasbg.fr Subject: Re: Appellation From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 24 Jan 2001 14:13:15 +0100 Send reply to: java@u-strasbg.fr ROUSSEL Yohann <yohann.roussel@criltelecom.com> writes: > > > J'aurais plutôt utilisé un pattern style "Marker Interface" : la > c'est le principe de la serialisation d'Obect et de l'interface > serializable non ? Tout à fait, Serializable ou Cloneable fonctionnent comme ça. -- Rodrigo
To: java@u-strasbg.fr Subject: Re: Appellation From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 24 Jan 2001 14:37:45 +0100 Send reply to: java@u-strasbg.fr "Thibaut Fagart" <tfagart@soleri.com> writes: > Comme la plupart des problemes de ce genre (Classe oiseau et aptitude a > voler), le probleme réside dans une mauvaise connaissance du " metier ". > Pour nous, un oiseau vole, mais pour le dictionnaire, voici la > definition d'un oiseau : En fait, le problème n'est pas spécifique à l'informatique et à l'objet, il concerne globalement toutes les créations d'ontologie de type treillis ou demi-treillis. En logique formelle, par exemple, il a donné lieu à tout un ensemble de logiques dite non-monotones parce qu'elles ont la particularité de pouvoir modifier la valeur de vérité d'un élément déjà vérifié ou falsifié. Dans le cas de l'informatique objet, on n'a pas forcément tous les mécanismes qu'on voudrait. Par exemple, en java on ne peut pas réduire la visibilité d'une méthode dans une classe fille, bien qu'on puisse l'augmenter. Cela a du sens au niveau de l'implémentation, mais on a typiquement là un exemple où cela pourrait avoir du sens. > La solution est donc de faire une classe Mere, abstraite, Oiseau dont > l'interface ne présente pas la méthode " voler " et deux sous classes > Ratite (toujours sans " voler ") et Carinate qui elle presente cette > méthode ... C'est effectivement une bonne solution (sûrement meilleure que celle que j'ai présentée dans ce cas de figure) à condition d'accepter ce niveau supplémentaire dans la hiérarchie. Si on prend l'exemple de Object, est-ce qu'il aurait été acceptable de créer deux classes filles, CloneableObject et NonCloneableObject ? A la rigueur, pourquoi pas. Mais que faire dans ce cas de Serializable ? Faut-il créer à nouveau une nouvelle strate dans la hiérarchie, avec CloneableSerializableObject, CloneableNonSerializableObject, etc. ? Déjà, la réponse est plutôt non. Entre le pattern "Marker Interface" et la granularisation de l'ontologie, je pense qu'il faut faire le choix en fonction de l'ensemble du problème. Pour le cas des oiseaux, je soupçonne qu'il y aurait d'autres exceptions qui poseraient problèmes avec l'ontologie que tu proposes (mais honnêtement, je n'ai aucun exemple en tête, n'ayant aucune connaissance du domaine). Sinon on peut aussi utiliser une modélisation systémique, ou un ensemble de treillis de propriétés (par ex. un treillis des animaux, un treillis des moyens de locomotion, un autre avec le modes d'alimentation, etc., et des relations qui associent les éléments d'un treillis avec ceux des autres treillis...) je ne sais pas si c'est très clair tel que je l'explique, mais c'est pas grave car ce n'est pas une très bonne idée de toute façon, dans la mesure où ça implique une complexité trop importante pour que ça soit facilement maintenable (AMHA)... :-) -- Rodrigo
To: java@u-strasbg.fr Subject: Re: Appellation From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 24 Jan 2001 14:56:19 +0100 Send reply to: java@u-strasbg.fr "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr> writes: > J'avais remarqué que vu certains des problèmes qu'on se pose sur cette > liste, il y a des moments où on comprend mieux de quoi on cause si on a > fait philo qu'informatique... Bon OK, en plus de la certif Java je me > programme une certif philo et je me réinsère dans la liste :-)) ... @ ++ > ! Pas la peine : http://www.charabia.net/generation/index.php3?voir=affiche&gen=essais_philosophiques :-) -- Rodrigo
Date sent: Wed, 24 Jan 2001 15:32:15 +0100
From: "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr>
Organization: CS-Institut ( http://www.csinstitut.fr )
To: java@u-strasbg.fr
Subject: Re: Appellation
Send reply to: java@u-strasbg.fr
Salut !
Rodrigo Reyes a écrit :
> > J'avais remarqué que vu certains des problèmes qu'on se pose sur cette
> > liste, il y a
> des moments où on comprend mieux de quoi on cause si on a fait philo
> qu'informatique... Bon OK, en plus de la certif Java je me programme une
> certif philo et je me réinsère dans la liste :-)) ... @ ++ !
>
> Pas la peine :
>
> http://www.charabia.net/generation/index.php3?voir=affiche&gen=essais_ph
> ilosophiques
>
Excellent, Rodrigo :-) !
C'est vrai que vu le niveau de discussion on a parfois besoin de pêter les
plombs pour se remettre d'applomb (humour). J'en ai même vu passer un dans
la liste qui proposait sérieusement de "granulariser la toxinomie"... Là
ça fout vraiment les jetons.
@++ !
--
^
° ° Eric LEMAITRE
/ V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS)
// \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX
Certified)
/ ( ) \ Responsable de formation pour les filières Internet et Linux
(Head of Internet/Linux Education Department)
^~^
Date sent: Wed, 24 Jan 2001 16:23:58 +0100 From: Guillaume Desnoix <guillaume.desnoix@cetmef.equipement.gouv.fr> To: java@u-strasbg.fr Subject: Re: Appellation Send reply to: java@u-strasbg.fr Eric LEMAITRE: > J'en ai m?me vu passer un dans la liste qui proposait s?rieusement de > "granulariser la toxinomie"... L? ?a fout vraiment les jetons. Je n'ai pas recu ce message mais il devait s'agir de la taxinomie ;-). C'est effectivement une bonne solution. Par ailleurs, je pense que l'heritage d'implementation va effectivement disparaitre a moyen terme... Pour Rodrigo: ah si j'avais eu un tel outil pour le bac!
Date sent: Wed, 24 Jan 2001 17:32:34 +0100
From: "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr>
Organization: CS-Institut ( http://www.csinstitut.fr )
To: java@u-strasbg.fr
Subject: Re: Appellation
Send reply to: java@u-strasbg.fr
Salut la liste !
Guillaume Desnoix a écrit :
> Eric LEMAITRE:
> > J'en ai m?me vu passer un dans la liste qui proposait s?rieusement de
> > "granulariser la toxinomie"... L? ?a fout vraiment les jetons.
>
> Je n'ai pas recu ce message mais il devait s'agir de la taxinomie ;-).
> C'est effectivement une bonne solution. Par ailleurs, je pense que
> l'heritage d'implementation va effectivement disparaitre a moyen
> terme... Pour Rodrigo: ah si j'avais eu un tel outil pour le bac!
Au secours ! Non seulement il y en a qui lisent ces formules, mais en plus
ils les comprennent ! Pire ils corrigent... Ben non, "granulariser la
taxinomie" je n'ai pas compris, mais si on me rappelait ce que "taxinomie"
veut dire ça irait peut être mieux.
@ ++ !
--
^
° ° Eric LEMAITRE
/ V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS)
// \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX
Certified)
/ ( ) \ Responsable de formation pour les filières Internet et Linux
(Head of Internet/Linux Education Department)
^~^
Date sent: Wed, 24 Jan 2001 11:53:44 -0500 From: Olivier Thomann <thomann@home.com> To: java@u-strasbg.fr Subject: Re: Appellation Send reply to: java@u-strasbg.fr Eric LEMAITRE wrote: > Ben non, "granulariser la taxinomie" je n'ai pas compris, mais si on me > rappelait ce que "taxinomie" veut dire ça irait peut être mieux. http://www.francophonie.hachette-livre.fr/cgi-bin/sgmlex2?T.SCIP.TL0064000 -- Olivier
Date sent: Wed, 24 Jan 2001 18:07:01 +0100
From: "Eric LEMAITRE" <eric.lemaitre@csinstitut.fr>
Organization: CS-Institut ( http://www.csinstitut.fr )
To: java@u-strasbg.fr
Subject: Re: Appellation
Send reply to: java@u-strasbg.fr
Salut !
Olivier Thomann a écrit :
> Eric LEMAITRE wrote:
> > Ben non, "granulariser la taxinomie" je n'ai pas compris, mais si on
> > me rappelait ce que "taxinomie" veut dire ça irait peut être mieux.
> http://www.francophonie.hachette-livre.fr/cgi-bin/sgmlex2?T.SCIP.TL00640
> 00
Merci pour le dictionnaire français en ligne, je le mets dans mes favoris
:-)) .
@ ++ !
--
^
° ° Eric LEMAITRE
/ V \ Ingénieur CNAM (CNAM Computer Engineer, MSCS)
// \\ Ingénieur et Formateur certifié Linux Red-Hat (RHCE & RHCX
Certified)
/ ( ) \ Responsable de formation pour les filières Internet et Linux
(Head of Internet/Linux Education Department)
^~^
From: "Cedric Beust" <cedric@beust.com> To: <java@u-strasbg.fr> Subject: RE: Appellation Date sent: Wed, 24 Jan 2001 10:17:48 -0800 Send reply to: java@u-strasbg.fr > From: Eric LEMAITRE [mailto:eric.lemaitre@csinstitut.fr] > Tu as tout à fait raison, c'est bien tout le problème : les Oiseaux en > général volent à 99%, seules quelques exceptions du genre pingouin ne > volent pas alors "exceptions" est le mot-cle. Tous les oiseaux devraient implementer voler() et ceux qui ne le peuvent pas devraient lancer une exception. -- Cedric
From: "Cedric Beust" <cedric@beust.com> To: <java@u-strasbg.fr> Subject: RE: Appellation Date sent: Wed, 24 Jan 2001 10:22:03 -0800 Send reply to: java@u-strasbg.fr > From: Rodrigo Reyes [mailto:rodrigor@in-fusio.com] > Dans le cas de l'informatique > objet, on n'a pas forcément tous les mécanismes qu'on voudrait. Par > exemple, en java on ne peut pas réduire la visibilité d'une méthode > dans une classe fille, bien qu'on puisse l'augmenter. Cela a du sens au > niveau de l'implémentation, mais on a typiquement là un exemple où cela > pourrait avoir du sens. Non, cela violerait les principes elementaires orientes-objet auxquels tous les programmeurs sont habitues actuellement. L'un d'entre eux est le principe de substitution, qui dit que toute instance d'une sous-classe peut etre utilisee en lieu de la classe-mere. Ce que tu suggeres ferait casser quantite de code. voler() pourrait tout simplement declarer une OperationNotSupportedException et ce serait aux appelants d'agir en consequence si cette exception est lancee. -- Cedric
Date sent: Wed, 24 Jan 2001 19:29:33 +0100 From: Guillaume Desnoix <guillaume.desnoix@cetmef.equipement.gouv.fr> To: java@u-strasbg.fr Subject: Re: Appellation Send reply to: java@u-strasbg.fr > http://www.francophonie.hachette-livre.fr/cgi-bin/sgmlex2?T.SCIP.TL00640 > 00 Toute mes excuses, je n'avais jamais entendu 'taxonomie'. D'apres le dico, ce mot est equivalent a taxinomie mais il semble etre employe plus souvent (13600 contre 1650 dixit www mais seulement 3920 contre 1480 pour les pages francophones).
To: java@u-strasbg.fr Subject: Re: Appellation From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 25 Jan 2001 09:47:41 +0100 Send reply to: java@u-strasbg.fr "Cedric Beust" <cedric@beust.com> writes: > Non, cela violerait les principes elementaires orientes-objet auxquels > tous les programmeurs sont habitues actuellement. L'un d'entre eux est > le principe de substitution, qui dit que toute instance d'une > sous-classe peut etre utilisee en lieu de la classe-mere. Ce que tu > suggeres ferait casser quantite de code. Attend, je ne suggère rien de tout cela, j'évoque simplement certaines limites de l'"OO" tel qu'on l'utilise actuellement. Tu est tout de même d'accord sur le fait qu'il peut y avoir besoin d'un héritage non-monotone de propriétés, et que les solutions suggérées (par exemple celles que toi ou moi suggérons ci-dessous) ne sont que des bidouilles destinées à contourner le problème ? > voler() pourrait tout simplement declarer une > OperationNotSupportedException et ce serait aux appelants d'agir en > consequence si cette exception est lancee. Oui, ou utiliser un marquage, comme je le suggérais. Disons qu'avec le marquage on peut avoir l'information à l'avance, et catégoriser les objets en fonction de cette propriété (si besoin est). -- Rodrigo
From: "Thibaut Fagart" <tfagart@soleri.com> To: <java@u-strasbg.fr> Subject: RE: Appellation Date sent: Thu, 25 Jan 2001 10:33:53 +0100 Send reply to: java@u-strasbg.fr Je souhaiterais rebondir sur ce commentaire Eric LEMAITRE a ecrit >>Comme la plupart des problemes de ce genre (Classe oiseau et aptitude a > >voler), le probleme réside dans une mauvaise connaissance du " metier > >". >C'est vrai au fond, c'est tout le problème de faire du "vrai orienté >objet" donc >de la réutilisation, le problème qui tue c'est qu'il faut avoir d'avance une >idée des développements qu'on va nous demander pour faire des classes vraiment >génériques dès le départ. [...] Oui, il faut connaître le métier pour pouvoir modéliser , mais ca me paraît evident. Et se dire que l'on va faire du code/une analyse directement réutilisable sans adaptation a des domaines auxquels on n'a pas reflechi tient du rêve (meme s'il est beau :) ) Quand on analyse un systeme, on analyse LE systeme , pas ce qui n'en fait pas partie. On peut avoir en plus des contraintes stipulant que si on ne s'interesse dans un premier temps qu'aux oiseaux qui volent, on voudra s'interesser " plus tard " aux oiseaux qui ne volent pas. La, notre boulot a nous analystes est d'analyser les impacts de cette elargissement, dans notre cas rajouter un niveau dans la hiérarchie, et les couts associés. Le choix de prendre une solution plutot que l'autre (une " bidouille " du style java.util.Collection ou celles presentees dans les contributions precedentes, avec un NotSupportedException), n'est pas de notre ressort mais de celui de la maîtrise d'ouvrage ou du client. D'une maniere générale, on peut ESSAYER de faire un modele extensible facilement, mais on a aucune garantie que ca se fera a cout nul. >>Pour nous, un oiseau vole, mais pour le dictionnaire, voici la >>definition d'un >> oiseau : >> oiseau n. m. 1. Vertébré ovipare, ............. Deux sous-classes sont >> représentées actuellement: les ratites, sans bréchet et inaptes au vol, et les >> carinates, dont le bréchet supporte les muscles nécessaires au vol. >Ah t'ain... déjà qu'on a parfois du mal à causer couramment interface, héritage, >délégation, instance,... et tout le toutim, maintenant en plus faut connaître >par coeur le dictionnaire pour modéliser... >J'avais remarqué que vu certains des problèmes qu'on se pose sur cette liste, il >y a des moments où on comprend mieux de quoi on cause si on a fait philo >qu'informatique... Bon OK, en plus de la certif Java je me programme une certif >philo et je me réinsère dans la liste :-)) ... @ ++ ! Quand je donnais la definition du dictionnaire, c'est la definition qu'aurait du nous donner le client ou la maitrise d'ouvrage. Et ce probleme des oiseaux est un bon exemple des ecueils de l'analyse d'un probleme. La signification que nous (analystes non spécialistes du métier) donnons a un terme n'est pas la meme que celle des experts du metier, or ce systeme DEVRA gérer le métier. Donc moi je dirais qu'un modele ou la méthode voler est sur la classe Oiseau est un modèle FAUX ou au moins inexact de la réalité, reste a savoir si le cas des oiseaux qui ne VOLENT PAS est a prendre en compte dans le systeme Thibaut Fagart Expert et Architecte Java, Analyste UML Soleri Ima