| Accueil de l'archive | Service proposé par Hervé AGNOUX |
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr> To: java@u-strasbg.fr Date sent: Wed, 25 Oct 2000 21:31:41 +0200 Subject: final static en uml Priority: normal Send reply to: java@u-strasbg.fr Je continue avec mes questions à 100 balles, quelle serait selon vous la meilleure équivalence en UML de la déclaration "final static" (une constante, quoi) du Java ? Merci pour vos réponses. -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
From: Bonnet Gilles <gilles.bonnet@CLERMONT.cemagref.fr>
To: "'java@u-strasbg.fr'" <java@u-strasbg.fr>
Subject: RE: final static en uml
Date sent: Thu, 26 Oct 2000 08:15:32 +0200
Send reply to: java@u-strasbg.fr
Si l'objectif est d'obtenir cela
-----
public class MaClasse
{
protected static final int unAttribut = 865;
public static int getUnAttribut () {
return MaClasse.unAttribut;
}
}
-----
l'attribut doit être déclaré "de classe" et accompagné d'une tagged value
"final" de plus dans le cadre de la génération automatique des accesseurs,
seul le get... est généré
il faut donc aussi penser à l'initialiser dans l'AGL (ici objecteering)
-----Message d'origine-----
De : Herve AGNOUX [mailto:hagnoux@mail.club-internet.fr]
Envoyé : mercredi 25 octobre 2000 21:32
À : java@u-strasbg.fr
Objet : final static en uml
Je continue avec mes questions à 100 balles, quelle serait selon
vous la meilleure équivalence en UML de la déclaration "final static" (une
constante, quoi) du Java ?
Merci pour vos réponses.
--
Hervé AGNOUX hagnoux@mail.club-internet.fr
Faites vos sites avec des formulaires electroniques :
http://www.diaam.com
Date sent: Thu, 26 Oct 2000 08:50:07 +0200
From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr>
Subject: Re: final static en uml
To: java@u-strasbg.fr
Send reply to: java@u-strasbg.fr
j'aimerai connaitre l'interet de mettre une constante protected et donc
etre oblige de lui faire un accesseur???? imagine que c'est la constante
qui va etre accedee quelques milliers de fois en tres peut de temps, pour
te rendre compte fait un test avec et sans "getter"
maintenant, je n'ai pas de reponse pour la question UML, pour l'unique
raison qu'UML(et essentiellement le diagramme le classe)ne me sert qu'a
faire de representation ponctuelle de mes projets et que ces diagrammes
sont tout simplement commentes pour expliquer ce que je ne sais pas
represente en UML(et que je ne veux pas passer trois plombes a chercher)
tout ceci pour en arrive a ma deuxieme question:
Pourquoi dans les phases de conception faut il s'embourber dans des
methodologies que seul quelques experts (rois de la theorie) semblent
maitriser?? je pense que l'on pert un temps fou a essayer de trouver
comment on peut representer tel ou tel point specifique d'un language,
alors qu'un graphique clair et commente par quelques ligne sur les points
plus techniques sera mis en place beaucoup plus vite, comprehensible cette
fois-ci par tout le monde et correspondra exactement aux contraintes que
vous imposent votre (ou vos) langage(s) associe(s) a votre projet
A+
Philippe.
Bonnet Gilles wrote:
> Si l'objectif est d'obtenir cela
> -----
> public class MaClasse
> {
> protected static final int unAttribut = 865;
> public static int getUnAttribut () {
> return MaClasse.unAttribut;
> }
>
> }
> -----
> l'attribut doit être déclaré "de classe" et accompagné d'une tagged
> value "final" de plus dans le cadre de la génération automatique des
> accesseurs,
> seul le get... est généré
> il faut donc aussi penser à l'initialiser dans l'AGL (ici objecteering)
>
> -----Message d'origine-----
> De : Herve AGNOUX [mailto:hagnoux@mail.club-internet.fr]
> Envoyé : mercredi 25 octobre 2000 21:32
> À : java@u-strasbg.fr
> Objet : final static en uml
>
> Je continue avec mes questions à 100 balles, quelle serait selon
> vous la meilleure équivalence en UML de la déclaration "final static"
> (une constante, quoi) du Java ?
>
> Merci pour vos réponses.
>
> --
> Hervé AGNOUX hagnoux@mail.club-internet.fr
> Faites vos sites avec des formulaires electroniques :
> http://www.diaam.com
From: Bonnet Gilles <gilles.bonnet@CLERMONT.cemagref.fr>
To: "'java@u-strasbg.fr'" <java@u-strasbg.fr>
Subject: RE: final static en uml
Date sent: Thu, 26 Oct 2000 08:59:55 +0200
Send reply to: java@u-strasbg.fr
pour répondre à la première observation
Tu peux en 10 s et pas trois plombes obtenir ceci en posant un tag
"noaccessor"
et en forçant la déclaration public (en objet un attribut est par défaut
privé) ----- public class MaClasse {
public static final int unAttribut = 865;
}-----
Quand à la maitrise d'une méthodologie UML, comme le disait récemment un
autre message quand on y a travaillé à plusieurs sur un projet un tant
soit peu important + de 300 classes on en perçoit très vite l'apport.
C'est maîtrisable relativement facilement. et je ne pense vraiment pas que
l'on se soit "embourbés" en la matière bien au contraire pour avoir fait
de la pratique après la théorie.
Il sûrement des membres de la liste qui sont beaucoup plus qualifiés que
moi pour s'exprimer sur le fond.
-----Message d'origine-----
De : Philippe Merlaud [mailto:philippe.merlaud@natexiscapital.fr]
Envoyé : jeudi 26 octobre 2000 08:50
À : java@u-strasbg.fr
Objet : Re: final static en uml
j'aimerai connaitre l'interet de mettre une constante protected et donc
etre oblige de lui faire un accesseur???? imagine que c'est la constante
qui va etre accedee quelques milliers de fois en tres peut de temps, pour
te rendre compte fait un test avec et sans "getter"
maintenant, je n'ai pas de reponse pour la question UML, pour l'unique
raison qu'UML(et essentiellement le diagramme le classe)ne me sert qu'a
faire de representation ponctuelle de mes projets et que ces diagrammes
sont tout simplement commentes pour expliquer ce que je ne sais pas
represente en UML(et que je ne veux pas passer trois plombes a chercher)
tout ceci pour en arrive a ma deuxieme question:
Pourquoi dans les phases de conception faut il s'embourber dans des
methodologies que seul quelques experts (rois de la theorie) semblent
maitriser?? je pense que l'on pert un temps fou a essayer de trouver
comment on peut representer tel ou tel point specifique d'un language,
alors qu'un graphique clair et commente par quelques ligne sur les points
plus techniques sera mis en place beaucoup plus vite, comprehensible cette
fois-ci par tout le monde et correspondra exactement aux contraintes que
vous imposent votre (ou vos) langage(s) associe(s) a votre projet
A+
Philippe.
Bonnet Gilles wrote:
> Si l'objectif est d'obtenir cela
> -----
> public class MaClasse
> {
> protected static final int unAttribut = 865;
> public static int getUnAttribut () {
> return MaClasse.unAttribut;
> }
>
> }
> -----
> l'attribut doit être déclaré "de classe" et accompagné d'une tagged
> value "final" de plus dans le cadre de la génération automatique des
> accesseurs,
> seul le get... est généré
> il faut donc aussi penser à l'initialiser dans l'AGL (ici objecteering)
>
> -----Message d'origine-----
> De : Herve AGNOUX [mailto:hagnoux@mail.club-internet.fr]
> Envoyé : mercredi 25 octobre 2000 21:32
> À : java@u-strasbg.fr
> Objet : final static en uml
>
> Je continue avec mes questions à 100 balles, quelle serait selon
> vous la meilleure équivalence en UML de la déclaration "final static"
> (une constante, quoi) du Java ?
>
> Merci pour vos réponses.
>
> --
> Hervé AGNOUX hagnoux@mail.club-internet.fr
> Faites vos sites avec des formulaires electroniques :
> http://www.diaam.com
Date sent: Thu, 26 Oct 2000 09:43:37 +0200
From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr>
Subject: Re: final static en uml
To: java@u-strasbg.fr
Send reply to: java@u-strasbg.fr
Arf j'avais oublie oublie de mettre public desole, mais c'etait a ta
conclusion que je voulais en venir ;)) et donc de toute facon le "getter"
est inutile. une petite precision un attribut (sans modificateur d'acces
et en java) est plus que prive par defaut, tu ne pourra pas y acceder via
une classe interne, en gros sa visibilite ne se limite qu'a la classe
Pour UML( je lacherrai pas le morceau ;)) )
en ce moment je suis sur un projet qui a depasse les 300 classes depuis un
certain temps, nous somme trois developpeurs/concepteurs dessus et pour ce
qui est d'UML et bien on ne s'en sert que de maniere superficielle, pour
l'unique raison que la methode ne fourni pas les outils (intuitifs et
comprehenssibles par le commun des mortels) qui correspondent a notre
projet. Et avant ce projet, j'etais (du cote de la production cette fois
ci) sur un projet du meme type d'architecture (mais dans proportion bien
plus importante, environs un centaine de personnes sur le projet,
utilisant C++ python et XML(et je ne te parle pas du nombre de sources
presents, c'etait de l'ordre du millier)) et l'architecte du projet ne
nous a quasiment jamais fait de presentation global UML du systeme (par ce
qu'il allait plus vite et etait plus clair en faisant des graphs
commentes) et sont projets est operationnel et en cours d'utilisation.
Sinon et je le repete, je pense qu'il ne sert a rien de se forcer a faire
de l'UML ou du meurise ou je ne sais quoi d'autre, on peut etre tout aussi
clair voir meme plus autrement. Par contre ca peut etre un bon support
dans certain cas.
Bonnet Gilles wrote:
> pour répondre à la première observation
> Tu peux en 10 s et pas trois plombes obtenir ceci en posant un tag
> "noaccessor"
> et en forçant la déclaration public (en objet un attribut est par défaut
> privé) ----- public class MaClasse {
> public static final int unAttribut = 865;
>
> }-----
> Quand à la maitrise d'une méthodologie UML, comme le disait récemment un
> autre message quand on y a travaillé à plusieurs sur un projet un tant
> soit peu important
> + de 300 classes on en perçoit très vite l'apport.
>
> C'est maîtrisable relativement facilement. et je ne pense vraiment pas
> que l'on se soit "embourbés" en la matière bien au contraire pour avoir
> fait de la pratique après la théorie.
>
> Il sûrement des membres de la liste qui sont beaucoup plus qualifiés que
> moi pour s'exprimer sur le fond.
>
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr> To: java@u-strasbg.fr Date sent: Thu, 26 Oct 2000 11:08:34 +0200 Subject: RE: final static en uml Priority: normal Send reply to: java@u-strasbg.fr Le 26 Oct 00, Bonnet Gilles a écrit : > l'attribut doit être déclaré "de classe" et accompagné d'une tagged > value "final" de plus dans le cadre de la génération automatique des > accesseurs, > seul le get... est généré > il faut donc aussi penser à l'initialiser dans l'AGL (ici objecteering) > Si je comprends bien, ton exemple présente une classe avec un simple attribut constant. Si je vais plus loin, comment fait-on pour présenter une sorte de pool de constantes ? Imaginons une application internationale dialoguant avec plusieurs machines. On a les constantes pour les expressions courantes (FICHIER = File, Fichier...), et les URLS des machines (on peut parler d'annuaire, par exemple), et sans doute plein d'autres choses. Quelle est la meilleure façon de procéder au niveau des constantes ? Est-il mieux, comme ton exemple le suggère, de les distribuer dans les classes qui décrivent les objets concernés ? Et, au niveau des liens, y a-t-il une façon spéciale de communiquer avec une constante (qui peut être un objet, comme ton exemple de le suggère pas) ? Par exemple soit le simple problème des fichiers de propriétés. Si tu as une propriété type "couleur.bord.fenêtre=rouge", tu auras quelque part dans ton code "public static final String COULEUR_BORD_FENETRE = "couleur.bord.fenetre"" (à moins que vous ne procediez autrement). Quand on a deux trois propriétés dans deux trois classes, ça va, mais quand on en a plétore ? On se retrouve avec 150 fichiers de propriétés ! Quel secours peut nous apporter UML pour organiser cette question ? (Finalement c'est un véritable cours de UML que je vous demande ! Merci d'avance !) -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
Date sent: Thu, 26 Oct 2000 11:20:28 +0200 From: William Dodé <wilk@chez.com> Send reply to: wilk@chez.com Organization: Informaticien Indépendant To: java@u-strasbg.fr Subject: Re: final static en uml Philippe Merlaud a écrit : > > Sinon et je le repete, je pense qu'il ne sert a rien de se forcer a > faire de l'UML ou du meurise ou je ne sais quoi d'autre, on peut etre > tout aussi clair voir meme plus autrement. Par contre ca peut etre un > bon support dans certain cas. Enfin quelqu'un privilégiant la clarté et l'intuition plutôt que la théorie ! bye -- William Dodé --- Informaticien Indépendant http://www.chez.com/wilk <mailto:wilk@chez.com>
Date sent: Thu, 26 Oct 2000 02:56:36 -0700 (PDT) From: vincent dupont <berzerk666@yahoo.com> Subject: RE: final static en uml To: java@u-strasbg.fr Send reply to: java@u-strasbg.fr heu... question stupide, c'est quoi UML?? ===== -------------------- Vincent Dupont dupont@exco.ucl.ac.be http://membres.tripod.fr/vdupont/ __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/
From: Olivier Guérin <olivier.guerin@softeam.fr> To: <java@u-strasbg.fr> Subject: Re: final static en uml Date sent: Thu, 26 Oct 2000 12:26:25 +0200 Send reply to: java@u-strasbg.fr ----- Original Message ----- From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr> Sent: Thursday, October 26, 2000 8:50 AM Subject: Re: final static en uml [...] > imagine que c'est la constante qui va etre accedee quelques milliers de > fois en tres peut de temps, pour te rendre compte fait un test avec et > sans "getter" Si tu as un bon compilateur il n'y a pas de différence en terme de performance entre un accès direct et un accès par accesseur. [...] > je pense que l'on pert un temps fou a essayer de trouver comment on peut > representer tel ou tel point specifique d'un language, alors qu'un > graphique clair et commente par quelques ligne sur les points plus > techniques sera mis en place beaucoup plus vite, comprehensible cette > fois-ci par tout le monde et correspondra exactement aux contraintes que > vous imposent votre (ou vos) langage(s) associe(s) a votre projet L'objectif d'UML est justement d'apporter une notation claire partagée par tous. Cela évite à chaque fois qu'on expose un problème de devoir d'abord expliquer sa notation puis son problème. S'il y a un symbole qu'on ne connait pas dans un diagramme, il suffit de se référer à son manuel UML plutôt que de demander au concepteur du diagramme de l'expliquer. D'un autre côté, on n'est pas obligé de tout connaître d'UML. On connait tous les principales notations des diagrammes de classe et des diagrammes d'état, ce qui est déjà une bonne base pour le dialogue. S'il y a une notion qu'on ne sait pas représenter en UML, c'est certainement dû au fait qu'on ne l'utilise pas souvent. Dans ce cas, je pense aussi qu'il n'est pas forcément nécessaire de passer son temps à chercher sa représentation. -- Olivier Guérin - SOFTEAM mailto:olivier.guerin@softeam.fr Get for FREE a highly professional UML case tool at www.objecteering.com Easily define, share and distribute your UML toolset for specific UML extensions at www.umlopenedition.com SOFTEAM ------- Think Object
Date sent: Thu, 26 Oct 2000 13:01:29 +0200 From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr> Subject: Re: final static en uml To: java@u-strasbg.fr Send reply to: java@u-strasbg.fr Olivier Guérin wrote: > ----- Original Message ----- > From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr> > Sent: Thursday, October 26, 2000 8:50 AM > Subject: Re: final static en uml > > [...] > > imagine que c'est la constante qui va etre accedee quelques milliers > > de fois en tres peut de temps, pour te rendre compte fait un test avec > > et sans "getter" > > Si tu as un bon compilateur il n'y a pas de différence en terme de > performance entre un accès direct et un accès par accesseur. Pas de chance, mauvaise reponse ca na rien a voir avec le compilateur, c'est juste un probleme d'architecture ;)). A chaque fois que tu fais appelles a une methodes il y a un changement de contexte, c'est pour cela qu'un parametre de methode (si ce n'est pas un object)qui est modifie a l'interieur d'une methode retrouve sa valeur d'entree lorsque l'on sort de la methode(c'est clair???). Comme je l'ai dit faite un test, un avec acces avec "getter" et l'autre sans, et faite le avec 1000000000 d'iterations (c'est exagere mais d'une maniere visuelle c'est flagrant) > L'objectif d'UML est justement d'apporter une notation claire partagée > par tous. Cela évite à chaque fois qu'on expose un problème de devoir > d'abord expliquer sa notation puis son problème. S'il y a un symbole > qu'on ne connait pas dans un diagramme, il suffit de se référer à son > manuel UML plutôt que de demander au concepteur du diagramme de > l'expliquer. Rien que la tu compliques, un rond avec ecrit base de donnees a l'interieur, y a rien de plus clair et y a pas besoin de bouquin ;)) desole c'est gros. Et si tu n'as pas toujours l'occasion d'avoir le concepteur sous la main, perso je ne me balade pas avec un bouquin d'UML dans la poche. et de toute facon une doc claire est une doc qui se plie a n'importe quel lecteur et qui se suffit a elle meme > D'un autre côté, on n'est pas obligé de tout connaître d'UML. On connait > tous les principales notations des diagrammes de classe et des > diagrammes d'état, ce qui est déjà une bonne base pour le dialogue. S'il > y a une notion qu'on ne sait pas représenter en UML, c'est certainement > dû au fait qu'on ne l'utilise pas souvent. Dans ce cas, je pense aussi > qu'il n'est pas forcément nécessaire de passer son temps à chercher sa > représentation. pareil ;)) > > > -- > Olivier Guérin - SOFTEAM > mailto:olivier.guerin@softeam.fr > > Get for FREE a highly professional UML case tool at www.objecteering.com > > Easily define, share and distribute your UML toolset > for specific UML extensions at www.umlopenedition.com > > SOFTEAM > ------- Think Object
From: Olivier Guérin <olivier.guerin@softeam.fr> To: <java@u-strasbg.fr> Subject: Re: final static en uml Date sent: Thu, 26 Oct 2000 14:10:08 +0200 Send reply to: java@u-strasbg.fr ----- Original Message ----- From: Philippe Merlaud <philippe.merlaud@natexiscapital.fr> Subject: Re: final static en uml > Pas de chance, mauvaise reponse ca na rien a voir avec le compilateur, c'est > juste un probleme d'architecture ;)). A chaque fois que tu fais appelles a une > methodes il y a un changement de contexte, c'est pour cela qu'un parametre de > methode (si ce n'est pas un object)qui est modifie a l'interieur d'une > methode retrouve sa valeur d'entree lorsque l'on sort de la > methode(c'est clair???). Comme je l'ai dit faite un test, un avec acces > avec "getter" et > l'autre sans, et faite le avec 1000000000 d'iterations (c'est exagere mais > d'une maniere visuelle c'est flagrant) ??? Le compilateur peut reconnaitre les accesseurs des autres méthodes et remplacer chaque appel à ces accesseurs par leur corps (in-line expansion mecanism). Je te renvoie à l'excellent bouquin de Bertrand Meyer, "Object Oriented Software Construction" qui t'expliquera ça en détail (§7.10 Discussion sur l'optimisation des appels aux accesseurs, page 208 et suivantes de l'édition américaine). Concernant les problèmes de performance, j'ai effectivement testé les deux possibilités (avec et sans accesseur). Jikes (1.1.8) effectue les deux itérations dans exactement le même temps, Javac (1.3) avec une baisse de performance de 0.10 %. -- Olivier Guérin - SOFTEAM mailto:olivier.guerin@softeam.fr Get for FREE a highly professional UML case tool at www.objecteering.com Easily define, share and distribute your UML toolset for specific UML extensions at www.umlopenedition.com SOFTEAM ------- Think Object
Date sent: Thu, 26 Oct 2000 14:15:58 +0200
From: Guillaume Desnoix <guillaume-desnoix@memoire.com>
To: java@u-strasbg.fr
Subject: Re: final static en uml
Send reply to: java@u-strasbg.fr
Herve AGNOUX:
> Je continue avec mes questions à 100 balles, quelle serait selon
> vous la meilleure équivalence en UML de la déclaration "final static"
> (une constante, quoi) du Java ?
Pour 'final', l'usage est d'utiliser le stereotype {leaf}. Pour
'static', en general on souligne.
Guillaume
From: "Cedric Beust" <cedric@beust.com> To: <java@u-strasbg.fr> Subject: RE: final static en uml Date sent: Thu, 26 Oct 2000 10:07:35 -0700 Send reply to: java@u-strasbg.fr > From: Olivier Guérin [mailto:olivier.guerin@softeam.fr] > Le compilateur peut reconnaitre les accesseurs des autres méthodes et > remplacer chaque appel à ces accesseurs par leur corps (in-line > expansion mecanism). Seulement s'ils sont declares "final". Et meme dans ce cas, la derniere fois que j'ai regarde, aucun compilateur que j'ai teste ne faisait cette mise en ligne. -- Cedric
From: Olivier Guérin <olivier.guerin@softeam.fr> To: <java@u-strasbg.fr> Subject: Re: final static en uml Date sent: Fri, 27 Oct 2000 09:04:51 +0200 Send reply to: java@u-strasbg.fr Bonjour Cédric, > > Le compilateur peut reconnaitre les accesseurs des autres méthodes et > > remplacer chaque appel à ces accesseurs par leur corps (in-line > > expansion mecanism). > > Seulement s'ils sont declares "final". > > Et meme dans ce cas, la derniere fois que j'ai regarde, aucun > compilateur que j'ai teste ne faisait cette mise en ligne. Ce n'est pas au JIT de faire ce type d'optimisation ? J'imagine que lui seul sait si une méthode a été redéfinie ou pas dans un projet et peut la mettre en ligne en conséquence, même si elle n'est pas déclarée finale. Ca expliquerait peut-être que tu ne trouves pas d'optimisation au niveau du bytecode généré par les compilateurs ? -- Olivier Guérin - SOFTEAM mailto:olivier.guerin@softeam.fr Get for FREE a highly professional UML case tool at www.objecteering.com Easily define, share and distribute your UML toolset for specific UML extensions at www.umlopenedition.com SOFTEAM ------- Think Object
From: "Cedric Beust" <cedric@beust.com> To: <java@u-strasbg.fr> Subject: RE: final static en uml Date sent: Fri, 27 Oct 2000 00:25:28 -0700 Send reply to: java@u-strasbg.fr > From: Olivier Guérin [mailto:olivier.guerin@softeam.fr] > Ce n'est pas au JIT de faire ce type d'optimisation ? J'imagine que lui > seul sait si une méthode a été redéfinie ou pas dans un projet et peut > la mettre en ligne en conséquence, même si elle n'est pas déclarée > finale. Meme en supposant que le compilateur ait une vue globale du projet, il ne peut pas se permettre de faire cette optimisation si "final" n'est pas present. Si par la suite un classe fille redefinit cette methode (alors que ce n'etait pas le cas avant), le polymorphisme echouera etant donne que la methode aura ete inline'e dans la classe de base. -- Cedric WebLogic
To: java@u-strasbg.fr Subject: Re: final static en uml From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 27 Oct 2000 10:34:19 +0200 Send reply to: java@u-strasbg.fr "Cedric Beust" <cedric@beust.com> writes: > > Le compilateur peut reconnaitre les accesseurs des autres méthodes et > > remplacer chaque appel à ces accesseurs par leur corps (in-line > > expansion mecanism). > Seulement s'ils sont declares "final". > Et meme dans ce cas, la derniere fois que j'ai regarde, aucun > compilateur que j'ai teste ne faisait cette mise en ligne. Ca me paraît d'ailleurs normal. Faire cette conversion (accesseurs inlinés) dans la classe même où sont définies ces constantes, ça me semble facile, mais le faire en dehors de cette classe me semble très délicat à cause des dépendances. Par exemple, si j'ai une classe A et une constante A.C, avec un A.getC(), ça me semble risqué de faire l'inline dans une classe B, sachant que si je modifie après l'accesseur de A.getC() (pour rajouter un log, par exemple), la répercussion ne se fera pas sur B (puisque A ne dépend pas de B). Je suis complètement d'accord avec Philippe, mettre un accesseur sur une constante n'a pas beaucoup de sens, en tout cas en Java. -- Rodrigo
From: Olivier Guérin <olivier.guerin@softeam.fr> To: <java@u-strasbg.fr> Subject: Re: final static en uml Date sent: Fri, 27 Oct 2000 11:14:04 +0200 Send reply to: java@u-strasbg.fr Cédric: > Si par la suite un classe fille redefinit cette methode (alors que ce > n'etait pas le cas avant), le polymorphisme echouera etant donne que la > methode aura ete inline'e dans la classe de base. Rodrigo: > Par exemple, si j'ai une classe A et une constante A.C, avec un > A.getC(), ça me semble risqué de faire l'inline dans une classe B, > sachant que si je modifie après l'accesseur de A.getC() (pour rajouter > un log, par exemple), la répercussion ne se fera pas sur B (puisque A > ne dépend pas de B). Il y a un truc que je ne saisis plus... Il me semblait qu'un JIT compilait à la volée et ne modifiait pas les .class. Ainsi, j'étais persuadé qu'il pouvait très bien gérer les situations que vous décrivez en réanalysant le projet à chaque exécution. Je m'ai trompé ? A propos, mois aussi je suis d'accord sur le peu d'utilité des accesseurs sur une constante. Par contre je les trouve très utile sur les autres attributs et je trouverais dommage de s'en priver pour des raisons de performance (qui n'ont d'ailleurs pas l'air d'être si importants que ça). -- Olivier Guérin - SOFTEAM mailto:olivier.guerin@softeam.fr Get for FREE a highly professional UML case tool at www.objecteering.com Easily define, share and distribute your UML toolset for specific UML extensions at www.umlopenedition.com SOFTEAM ------- Think Object
To: java@u-strasbg.fr Subject: Re: final static en uml From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 27 Oct 2000 12:02:49 +0200 Send reply to: java@u-strasbg.fr Olivier Guérin <olivier.guerin@softeam.fr> writes: > Il y a un truc que je ne saisis plus... Il me semblait qu'un JIT > compilait à la volée et ne modifiait pas les .class. Ainsi, j'étais > persuadé qu'il pouvait très bien gérer les situations que vous décrivez > en réanalysant le projet à chaque exécution. Je m'ai trompé ? Pas du tout, je ne me plaçais tout simplement pas dans la situation d'une compilation avec un JIT; tu parlais d'ailleurs de tests avec jikes et javac. Sinon je suis bien d'accord qu'un JIT devrait pouvoir faire ça. La question à 110F (je surenchéris sur Hervé :-)) : le font-ils ? Question subsidiaire, quelle est la méthode utilisée ? > A propos, mois aussi je suis d'accord sur le peu d'utilité des > accesseurs sur une constante. Par contre je les trouve très utile sur > les autres attributs et je trouverais dommage de s'en priver pour des > raisons de performance (qui n'ont d'ailleurs pas l'air d'être si > importants que ça). Toutafé. Metoo. -- Rodrigo
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr>
To: java@u-strasbg.fr
Date sent: Fri, 27 Oct 2000 13:08:04 +0200
Subject: Re: final static en uml
Priority: normal
Send reply to: java@u-strasbg.fr
Le 26 Oct 00, Guillaume Desnoix a écrit :
>
> Pour 'final', l'usage est d'utiliser le stereotype {leaf}. Pour
> 'static', en general on souligne.
>
Merci, j'imaginais qu'en UML il y avait des choses plus... heu...
"étudiées" sur les constantes ! Je m'étonne que les gourous des
méthodes objets ne nous aient pas dit "Organisez les comme ceci
ou comme cela !" Moi j'ai comme combine de les mettre en
majuscule, je vois que je suis pratiquement au top de la recherche
en ce domaine ;-)))))))
--
Hervé AGNOUX hagnoux@mail.club-internet.fr
Faites vos sites avec des formulaires electroniques :
http://www.diaam.com
To: java@u-strasbg.fr Subject: Re: final static en uml From: Rodrigo Reyes <rodrigor@in-fusio.com> Date sent: 27 Oct 2000 15:34:17 +0200 Send reply to: java@u-strasbg.fr "Herve AGNOUX" <hagnoux@mail.club-internet.fr> writes: > ou comme cela !" Moi j'ai comme combine de les mettre en > majuscule, je vois que je suis pratiquement au top de la recherche en ce > domaine ;-))))))) MDR! Soumet un papier à la prochaine conf sur le sujet ! :-) -- Rodrigo