Discussion :

[alois.cochard]

Bonjour,

J'ai un problème un peu spéciale, en réalité ce n'est pas un vrai problème mais plutôt un soucis de conception que j'aimerais résoudre car j'adore la perfection ;-)

Je vais essayer de vous exposer le problème sans code concret, en cas de problème je posterais des sources ...

J'ai une classe appelée 'légume' qui contient une méthode STATIQUE nommée 'getFoo()' qui renvoie un entier.

Je crée maintenant une classe carotte et choux qui hérite de légume et qui surcharge la méthode 'getFoo' en renvoyant chacun des valeurs différente.

... voilà pour la présentation, maitenant voici mon problème :

J'ai une méthode dans une autre classe totalement indépendante du shéma récédent nommée 'processFoo' dont voici le prototype :

public void processFoo(Légume monLégume);

.... vous me voyez venir ? ... j'aimerais accéder à une méthode statique d'une classe correspondant à un objet instancié....

Pour l'instant je fait :

légume.getClass().getMethod("getFoo",argsType).invoke(null,args);

Mais je trouve cela vraiment pas jolis jolis... surtout niveau refactoring ou je risque d'avoir des problèmes... Je pourrais bien sur utiliser une méthode dynamique au lieu d'une statique qui accéde ensuite à une méthode statique... ce qui régle le problème du refactoring, mais je trouve pas très bien non plus... car sa doit ralentir l'exécution (ok je chipote...) une solution ?


Merci à tous pour votre aide, En espérant que cette requête n'est pas redondante... je n'ai pas reussi à trouver pareil question dans les archives...

A bientôt,

Alois Cochard
JXTA/Orexio/CannaGrower/...

PS: J'espère que mon langage technique est correcte et compréhensible...

[adiGuba]

Salut,

.... vous me voyez venir ? ... j'aimerais accéder à une méthode statique d'une classe correspondant à un objet instancié....

Tu mélanges methodes static et instance ! Une méthode static est indépendante des instances...

Mais je trouve cela vraiment pas jolis jolis... surtout niveau refactoring ou je risque d'avoir des problèmes...

Tout à fait d'accord !

Je pourrais bien sur utiliser une méthode dynamique au lieu d'une statique qui accéde ensuite à une méthode statique... ce qui régle le problème du refactoring, mais je trouve pas très bien non plus... car sa doit ralentir l'exécution (ok je chipote...) une solution ?

Tu chipotes !!!

Tu utilises une instance d'un objet, et tu veux exécuter une méthode selon cette instance : c'est une exécution dynamique !

En appelant via la réflection une méthode static, tu simules le comportement de l'exécution dynamique dans un concept static, et cela doit surement être bien moins "performant" que l'appel à une méthode dynamique (qui est très bien optimiser par la JVM).


Si tu ne veux pas utiliser de méthode dynamique, ne fait pas de POO et encore moins de Java...


a++

[alois.cochard]

Hello adiGuba,

Merci pour ta réponse, et en la lisant je me suis rendu compte que ce que j'esseye de faire, la JVM le fait déjà automatiquement... des fois je vais chercher beaucoup trop loin... enfaite j'avais envie de 'mâcher' le travail de la JVM.. mais c'est vrai que carrement à la compilation de la classe, le compilateur doit remarquer que la méthode dynamique accéde à un élément statique et du coup faire le lien direct...

Par contre je suis presque choqué par cette phrase :
'Si tu ne veux pas utiliser de méthode dynamique, ne fait pas de POO et encore moins de Java...'

Car en programmant tout en objet (obligé...), beaucoup de développeur Java font l'erreur d'oublier la notion d'élément statique et se retrouve avec des objets instanciés à de multiple reprise sans aucune nécessité ! ... alors que la notion statique est extrêmement utile pour être réellement performant en POO, notamment en utilisant les classes singleton ou encore d'autre pattern dans le genre...

Cette remarque pourrait me faire croire que vous n'avez pas compris l'utilité des élément statique ;-) ... mais à l'inverse de votre réaction je vais plutot supposer que vous avez une grande peur de voir des gens utiliser abusement des élément statique... les empêchant ainsi de comprendre les réel avantage de la POO... peut-être un peu trop l'habitude de répondre au personne venant d'autre langage de programmation ?

Bon je vais prendre des calmement et arrêté de remplacer la JVM par mon cerveau...

A bientot,

Alois Cochard

[adiGuba]

Car en programmant tout en objet (obligé...), beaucoup de développeur Java font l'erreur d'oublier la notion d'élément statique et se retrouve avec des objets instanciés à de multiple reprise sans aucune nécessité ! ... alors que la notion statique est extrêmement utile pour être réellement performant en POO, notamment en utilisant les classes singleton ou encore d'autre pattern dans le genre...

Je n'ai rien contre les éléments static lorsqu'ils sont neccessaire.

Mais dans ce cas là cela ressemble plus à une simulation d'invocation dynamique ( appeler une méthode statique différente selon le type réel d'une instance). Dans ce cas précis il n'y a aucun raison d'être en static.

Ce que je voulais dire c'est que l'invocation dynamique est une des bases de la POO (et en particulier de Java), et que si tu veux t'en passer pour X ou Y raison il vaut mieux changer de langage

a++

[alois.cochard]

Bonjour,

Enfaite le cas que j'ai exprimé dans mon 1er message correspond as un cas que l'on peut corriger en créant en effet une méthode dynamique comme je le prétendais et comme adiGuba m'as confirmé.

J'ai voulu appliquer ces modifications dans mon projet car je détéste ces compilations dynamique que j'ai utiliser... mais malheureusement me voilà confronter à la source du problème que j'avais oublier entre temps...

J'ai une méthode nommée 'getFoo' dont voici le prototype :

public int getFoo(Class fooType);

Enfaite j'aimerais de l'héritage aux niveau des class car la je passe un objet 'Class' mais sans compilation dynamique il m'est impossible d'accéder à une méthode statique ! comment faire ?

Je vois déjà une modification du langage qui permettrait de faire un prototype du genre :

public int getFoo(Class<Legume> fooType);


Mais j'espère que je me trompe et qu'il y'as une autre solution ?

Je peux de toute manière résoudre le problème en abordant la conception d'une manière différente mais qui serait malheureusement moins dynamique et moins parfaite a mon gout (... je hais les redondances de codes ...).

Je précise que cette méthode getFoo dans le cadre où elle est utilisée ne peut pas recevoir un objet instancié. Elle souhaite faire appel a une class dont on sait qu'elle hérite de légume... en l'occurrence en vérifiant avec un 'instanceof'.... mais il doit y avoir un autre moyen...

Je me suis fait comprendre ? Vous avez des idées ?

Merci beaucoup pour votre aide,

Alois Cochard

[gifffftane]

Je trouve que les méthodes static sont peu pratiques en java, et je les utilise seulement pour des sortes d'utilitaires de classe.

Les héritages et polymorphismes en particulier sont très mal gérés, à mon opinion.

Aussi pour ton cas, soit j'ai besoin de l'héritage, et alors je rendrais la méthode getFoo méthode d'instance, profitant ainsi de toute la mécanique d'instance, soit je leur donnerais une signature spéciale pour chaque classe, par exemple getFooDeClass1(), getFooDeClass2(), etc. Cela revient un peu à ton getFoo(Class1 fooType), sauf que c'est plus radical.

[alois.cochard]

Je trouve que les méthodes static sont peu pratiques en java, et je les utilise seulement pour des sortes d'utilitaires de classe.

Les héritages et polymorphismes en particulier sont très mal gérés, à mon opinion.

Je me sens moins seul :-) je vais poster un billet sur java.net histoire de voir l'avis des ricains et autres indiens... Pour l'instant j'utilisai que pour des utilitaire ou des class singleton... là j'avais envie de polymorphisme et d'héritage, et sérieux je suis un peu déçu... mais ceci doit avoir un sens au niveau de la conception du langage... j'espère avoir des précisions sur java.net.

Le changement de conception que j'ai envisagé permet de résoudre le problème avec ta première solution c-a-d une utilisant une instance... (et c'est ce que je vais faire) mais célà change pas mal de chose pour que cette instanciation prenne un sens réellement dynamique et utile... et non pas une sorte de 'sac à méthode' dynamique... qui du coup devrait plutôt suivre un pattern singleton et qui du coup me ferait me retrouver au même problème...

Bref tout ça dur à expliquer sans le contexte, mais merci à tous pour vos réponses, je vois qu'elle est la 'bonne' direction à prendre... et aussi d'avoir eu qqun qui as eu le même problème c'est toujours rassurent, je poste ici si je trouve d'autre infos.

Encore merci,

Alois Cochard

[adiGuba]

Je vois déjà une modification du langage qui permettrait de faire un prototype du genre :

public int getFoo(Class<Legume> fooType);

Heu ?! C'est déjà possible avec les Generics depuis Java 5.0...

Les héritages et polymorphismes en particulier sont très mal gérés, à mon opinion.

En même temps static signifie qu'on n'est pas lié à une instance... donc on ne peut pas vraiment parler d'héritage...


Pour en revenir au problème : a quoi doit servir tout cela exactement ?

a++

[alois.cochard]

Heu ?! C'est déjà possible avec les Generics depuis Java 5.0...

Enfaite j'ai utiliser la syntaxe des generics juste à titre d'exemple... le code indiquer ne se compile bien sur pas... ou seulement dans le compilateur interne à mon cerveau (et dans le tiens aussi apparemment )

En même temps static signifie qu'on n'est pas lié à une instance... donc on ne peut pas vraiment parler d'héritage...

J'ai enfin compris en lisant beaucoup de doc POO !

On peut parler d'héritage mais pas de polymorphisme... enfin au sens ou je l'entendais... (et dans le sens ou on l'utilise avec les objet dynamique... cf définition de doc officiel plus loin...)

Donc le polymorphisme n'existe pas dans les éléments static, pour ce faire il faudrait pouvoir crée des classes qui ne sont pas des classe 'Class' mais des classe héritée d'une classe personnalisée qui hérite elle même bien sur de la classe 'Class'... je ne parle pas de 'classe' qui peut hérité de tout ce qu'on veut mais de la classe 'Class'... il me parait impossible pour le compilateur de gérer ceci, pas la force de réfléchir à tout le processus mais je pense que c'est le coup du serpent qui se mort la queue.... ou alors sa devient super complexe au niveau syntaxe...

Et si l'on se réfère au documentation officiel (trouve plus le lien , mais un 'static polymorphism' dans google et c trouvé...) la notion de 'polymorphisme statique' n'est pas du tout ce que je voulais faire (qui n'existe tout simplement pas, comme expliqué juste en dessus) ... mais ce n'est qu'un nom pour désigner l'utilisation de plusieurs prototype pour une seul méthode... j'appellerais sa plutôt le polymorphisme de méthode mais bon... ingénieurs, ingénieurs...

Par contre l'héritage existe, bel et bien... un ptit exemple pour prouver ce que je dit. Dans une classe 'Chien' j'ai une méthode static 'getFoo' si je crée un class vide (sans surchage) 'Doberman' qui hérite de Chien, je pourrais faire 'Doberman.getFoo()' sans problème c'est donc de l'héritage... en espérant ne pas mélanger les termes...

Pour en revenir au problème : a quoi doit servir tout cela exactement ?

Bon je vais esseyer de faire vite et simple

J'ai un jpanel qui gère une liste de matériel (icone+texte), j'ai donc les classes suivantes :

Hardware
Lamp extends Hardware
Heater extends Hardware

Donc un héritage simple à un seul niveau, à coter de cette liste j'ai un bouton '+' qui ouvre un menu contextuelle affichant les matériaux disponible.

Dans un soucis de dynamique j'ai stocker la liste des matérieux disponbile dans un tableaux de class, permettant ainsi d'ajouter un nouveau type de matériel sans modification de code.

--- Comme je faisais jusqu'as maitenant
Hardwarde, Lamp, Heater ont chacun une méthode getIcon static permettant d'obtenire l'icone à afficher

Exemple de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
ArrayList<Class>	hardwares;
Class			hardwareType;
 
for(hardwareType: hardwares){
	// Ce que je rêverais sutpidement de faire mais comme j'ai expliquer c tout simplement 'logiquement' impossible...
	//hardwareType.getIcon() //getIcon() est static !!
	// Ce que je faisais vraiment avec l'aide de mon imagination trop débordante...
	hardwareType.getMethod("getIcon").etc.etc.invoke()
}

--- Comme j'ai corrigé
Stupidement dans ce menu contextuelle j'ai gérer les descrition et les icone différament, tout simplement car j'ai ajouter les images après...
Surtout la description utilise un système de traduction qui fait que je n'aurais meme pas imaginer mettre la description du matériel dans la class elle même...

En gros j'ai maitenant créée une classe 'HardwareIcons', qui contient une méthode static que voici en résumé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static void getIcon(Class hardwareType){
	if(hardwareType==Lamp.getClass()){
		return...
	}
}

J'espère qu'on m'auras compris malgré mes expressions parfois étrange...

En tout les cas merci à tous, une de ces bonne discutions de programmeurs impossible à avoir avec les gens de son entourage

Alois Cochard

[adiGuba]

Enfaite j'ai utiliser la syntaxe des generics juste à titre d'exemple... le code indiquer ne se compile bien sur pas... ou seulement dans le compilateur interne à mon cerveau (et dans le tiens aussi apparemment )

Heu... Ce type de prototype est tout à fait correct (à partir de Java 5.0 évidemment), exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
interface Test {
	public int getFoo(Class<Number> fooType);
}

a++

[alois.cochard]

Heu... Ce type de prototype est tout à fait correct (à partir de Java 5.0 évidemment), exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
interface Test {
	public int getFoo(Class<Number> fooType);
}

a++

Ah ouais je l'utilise en plus... voilà pourquoi j'avais envie d'accéder au méthode static overide de Number sur le fooType du coup... comme avec les generic d'instance quoi !!

Donc la vérification de type (generic check) de l'héritage fonctionne bien mais le polymorphisme reste impossible... (logique vu ce que j'ai expliqué dans le post d'avant)

Je n'aurais pas du utiliser les caractères '<' et '>' dans mon exemple ou je voulais justement indiqué une nouvelle syntaxe imaginée permettant d'activé un 'héritage static'.. celà porte confusion avec la notion de generic...

En tout les cas cette exemple que j'ai donné n'est plus d'actualité vu ce que j'ai compris depuis... par contre c clair que la prototype et plus que correcte... voir même recommandée


A++

[bobuse]

Je trouve le problème de fond un peu tordu, ou alors je ne comprends rien.

Pour ton histoire de méthode getIcon static, moi je ferai tout simplement une map <Class, Icon> par exemple.

J'ai du mal à comprendre pourquoi tu veux absolument pas avoir d'instance ! Il me semble que le patron Strategy s'implémente classiquement en utilisant des méthodes (d'instance).
Où alors, ce sont les pointeurs de fonctions du C qui te manquent

Bref, je trouve tout ça bizarre

[alois.cochard]

Pour ton histoire de méthode getIcon static, moi je ferai tout simplement une map <Class, Icon> par exemple.

Oui tout à fait, c'est de cette manière que j'ai corriger, simplement dans l'exemple si dessus j'ai mis un if() imbriqué à la place d'une recherche sur une map... mais l'as tu parle d'une optimisation sur l'exemple de code que j'ai donner pour contourner le problème... mais pas du problème de fond...

J'ai du mal à comprendre pourquoi tu veux absolument pas avoir d'instance ! Il me semble que le patron Strategy s'implémente classiquement en utilisant des méthodes (d'instance).
Où alors, ce sont les pointeurs de fonctions du C qui te manquent

Tu n'as effectivement pas tout compris mais je me suis aussi je pense pas super bien exprimé.

Lorsque je me trouve dans le code qui génére le menu contextuelle je ne peux pas avoir accès à une instance de matériel car il n'y as encore aucune instance crée !! (je veux choisir quel type d'instance/matéril je veux crée justement ...)

Enfaite je voulais obtenire les icon en utilisant un pattern 'strategy' mais c'est impossible car je n'ai pas d'instance au moment ou j'ai besoin de l'icon... (et comme tu le dit très bien, un pattern strategy est construit avec des méthodes statiques... ) alors j'ai crée une sorte de 'factory' d'icone qui selon la classe donnée retourne le bonne icon trouvé dans la map...

Sinon j'esseye d'expliquer pourquoi il est impossible d'appliquer un pattern strategy en utilisant des méthodes statiques... je pense qu'en créant la possibilité de faire et d'utiliser des héritiers de la classe 'Class' serait impossible à gerer par compilateur qui ce mélangerais les pinceaux... cqfd

Est-ce plus claire comme ça ?

A+

Alois Cochard

[gifffftane]

En même temps static signifie qu'on n'est pas lié à une instance... donc on ne peut pas vraiment parler d'héritage...

Possible, mais enfin c'est pas une raison pour être maladroit dans l'expression ; en java le choix de la méthode effectivement appelée sur un objet change complètement selon que c'est une méthode statique ou d'instance, mais, à la simple lecture du code, rien ne permet de le découvrir, et c'est trompeur.

Par exemple, soit une classe B qui hérite de A avec dans toutes les deux une méthode M.

Si la méthode M est d'instance, une instance de la classe B activera la sienne, pareil pour A, c'est le fonctionnement connu.

Mais si M est une méthode statique, ce n'est plus la classe qui est significative pour le choix de la méthode, mais sa déclaration. Si je déclare un objet de classe A, même s'il est de classe B, comme j'en ai le droit, et que j'appelle la méthode M de cet objet, alors ce sera la méthode M de la classe A qui sera appelée, et non de la classe B comme tout le monde pourrait le croire.

Je trouve que c'est très maladroit comme syntaxe et, si je pouvais modifier ça, j'interdirais que l'on puisse appeler une méthode statique en se basant sur une instance.

Et puis si je pouvais refaire le monde je dirais qu'il ferait soleil tout le temps et qu'on ait de l'eau tout le temps aussi même au désert. Na.

[adiGuba]

Mais si M est une méthode statique, ce n'est plus la classe qui est significative pour le choix de la méthode, mais sa déclaration. Si je déclare un objet de classe A, même s'il est de classe B, comme j'en ai le droit, et que j'appelle la méthode M de cet objet, alors ce sera la méthode M de la classe A qui sera appelée, et non de la classe B comme tout le monde pourrait le croire.

Je trouve que c'est très maladroit comme syntaxe et, si je pouvais modifier ça, j'interdirais que l'on puisse appeler une méthode statique en se basant sur une instance.

Tu veux dire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
A a = new B();
a.M(); // c'est la méthode static M() de A qui est appelé

Pour moi c'est surtout une erreur de codage : une méthode static ne devrait pas être appelé avec une instance mais avec le type de la classe...

D'ailleur eclipse permet de générer un warning là dessus

a++

[alois.cochard]

Possible, mais enfin c'est pas une raison pour être maladroit dans l'expression ; en java le choix de la méthode effectivement appelée sur un objet change complètement selon que c'est une méthode statique ou d'instance, mais, à la simple lecture du code, rien ne permet de le découvrir, et c'est trompeur.

On est bien d'accord sur ce point... enfaite on aimerait un 'Super.' en plus du 'super.' ... toute la différence et dans la majuscule

Je trouve que c'est très maladroit comme syntaxe et, si je pouvais modifier ça, j'interdirais que l'on puisse appeler une méthode statique en se basant sur une instance.

Celà génére un warning il me semble ? mais c vrai qu'as mon avis aussi sa devrait généré une erreure... sinon imaginer le nombre de problème que cela peut lors de la lecture (humain) du code !!

Et puis si je pouvais refaire le monde je dirais qu'il ferait soleil tout le temps et qu'on ait de l'eau tout le temps aussi même au désert. Na.

Ah ouais idem ... allez attendons la programmation orientée aspect gifffftane et on pourrais le refaire le monde

A++

Alois Cochard

[alois.cochard]

Pour moi c'est surtout une erreur de codage : une méthode static ne devrait pas être appelé avec une instance mais avec le type de la classe...

D'ailleur eclipse permet de générer un warning là dessus

Ah on as répondu en même temps...

Que dans Eclipse le warning ??? donc il ont des specs différentes de sun... leur propre compilateur j'ai aussi entendu.. pourtant dans eclipse je choisis un jdk.. la je comprends plus rien... bref c'est hs, je vais me renseigné ailleurs pour ça..

[gifffftane]

D'ailleur eclipse permet de générer un warning là dessus

Avec juste raison. Mais c'est seulement une erreur de niveau convention d'écriture, un peu comme PMD ou d'autres outils te sortent quantités de warning si tu indentes pas bien, si tu mets des if sans accolades, etc.

Pour ce qui concerne le langage lui même c'est parfaitement permis, et sans le moindre warning.

[adiGuba]

Que dans Eclipse le warning ???

Oui. Enfin d'autres EDI/compilateur le propose peut-être, mais il n'est pas affiché par le compilateur javac de Sun...

donc il ont des specs différentes de sun...

Non les mêmes : l'appel d'une méthode static en utilisant un instance est permis par le langage. Mais rien n'empêche le compilateur de proposer d'autres warnings dans des cas posant problèmes (eclipse propose d'ailleurs un grand nombre de warning de ce type).

leur propre compilateur j'ai aussi entendu.. pourtant dans eclipse je choisis un jdk.. la je comprends plus rien...

Oui eclipse possède bien son propre compilateur, et il n'a besoin en réalité que d'un JRE. Ce dernier lui permet de vérifier les dépendances avec les classes de l'API standard...

Bien sûr il reste possible d'utiliser un JDK et je le conseille même car cela permet d'avoir la javadoc en tooltip, l'accès au source de l'API standard (via Ctrl+Clic), et d'utiliser les vrais nom de paramètres des méthodes (au lieu de arg0, arg1 etc.). Pour cela il faut cependant penser à installer les sources avec le JDK

a++

[alois.cochard]

Merci bien adiGuba pour toute ces précision !

A vrai dire j'avais pas trouver beaucoup d'info à ce sujet sur google, surement pas utilisé les bons mot clés

++