héritage de méthodes statiques

**behess** · 11/09/2008, 18h50

Bonjour,

le titre est spécialement posé pour être provocateur

En fait mon problème est le suivant :

J'ai plusieurs classes fille d'une SuperClasse qui doivent chacune être créées en fonction d'une chaine identifiable par un pattern (mais ne comportant pas le nom de la classe) et contenant des paramètres; en simplifiant :

"barbidule(1,2,3)" => Classe1 avec attributs initialisés à 1,2,3,
"barbabulle(A,B)" => Classe2 avec attributs initialisés à A,B,
"barbatruc" => Classe3 sans attributs

Comment faire ?

J'ai imaginé plusieurs solutions possibles :

utiliser un constructeur acceptant la chaine et retournant une exception en cas d'incompatibilité ; la fabrique essayera toutes les classes jusqu'à tomber sur la bonne (mauvais selon moi puisqu'on détourne les exceptions, qui en plus sont coûteuses), mais la conception est plutôt simple
utiliser une méthode de classe qui va nous dire si la classe peut être construite à partir de la chaine ; -> plus de soucis avec les exceptions, mais comment être sûr que les sous-classes implémentent bien la méthode de classe puisqu'on ne peut rendre ces méthodes abstaites au niveau de la super classe ? En plus impossible de faire du polymorphisme comme cela ! Seules les méthodes de réflexion sont capables de chercher une telle méthode sans poser problème.
solution dérivée : une méthode getInstance(String) mais on a le même soucis avec l'héritage de méthode statique !
dernière solution la plus propre : extraire la reconnaissance des chaines dans une fabrique, extraire les paramètres de la chaine proposée, puis construire la classe avec les bons paramètres directement (et plus avec la chaine), mais la reconnaissance est en dehors de la classe qui est censée être la seule au courant de la chose. On pourrait imaginer que ce soit la classe qui fournisse le pattern, mais on aurait encore le problème de la méthode qui doit absolument exister (donc issue d'une interface), mais du niveau classe et pas instance !

J'attends vos contre-propositions / critiques.

Merci à tous pour votre participation !

**behess** · 12/09/2008, 10h20

Finalement je pense que la dernière solution est la bonne, mais il ne faut pas tenter d'inclure le décodage du flux dans la classe, tant pis. Il vaut mieux utiliser une fabrique spécifique à chaque classe cible :

La fabrique générale va construire des fabriques spécifiques qui vont décoder le flux et qui renverront ou pas un objet bien construit selon sa validité.

Si l'objet est renvoyé, ok on a tout bon et on arrête la recherche.
Si l'objet n'est pas renvoyé, alors on continue avec le prochain décodeur.

Pour éviter de détruire/construire les mêmes décodeurs moult fois, on stocke les décodeurs dans une map et on les récupère à chaque traitement de flux.

Il peut être utile aussi d'utiliser des références faibles dans la map.

Comme quoi :

ça aide parfois d'expliquer son problème pour réussir à le résoudre !
la nuit porte conseil

**behess** · 12/09/2008, 11h30

Je veux juste rajouter que je suis frustré de ne pouvoir imposer la redéfinition d'une méthode statique / la présence d'un membre statique dans les classes filles en Java (et autres langages OO communs).

ça simplifierait bien les choses

**mister3957** · 13/09/2008, 10h41

Si si tu peux, grâce aux classes Traits, 'fin faut du C++, dans les autres langages je sais pas si c'est faisable.

**pseudocode** · 15/09/2008, 14h27

Envoyé par behess

Je veux juste rajouter que je suis frustré de ne pouvoir imposer la redéfinition d'une méthode statique / la présence d'un membre statique dans les classes filles en Java (et autres langages OO communs).

ça simplifierait bien les choses

En quoi cela simplifierait les choses pour ton problème ?

**behess** · 15/09/2008, 15h44

Si je pouvais imposer la redéfinition d'éléments de niveau classe, j'utiliserai la seconde solution :

Envoyé par solution 2

utiliser une méthode de classe qui va nous dire si la classe peut être construite à partir de la chaine ; -> plus de soucis avec les exceptions, mais comment être sûr que les sous-classes implémentent bien la méthode de classe puisqu'on ne peut rendre ces méthodes abstraites au niveau de la super classe ? En plus impossible de faire du polymorphisme comme cela ! Seules les méthodes de réflexion sont capables de chercher une telle méthode sans poser problème.

En effet, si je ne peux pas IMPOSER la re-définition des méthodes statiques, la méthode pourrait ne pas être re-définie et donc ce serait la méthode de la classe mère qui serait appelée ! Moi je voudrai que ce soit la méthode de la classe fille qui soit appelée, car elle a une logique différente de la classe mère (mais une sémantique identique).

**pseudocode** · 15/09/2008, 17h17

Envoyé par behess

Si je pouvais imposer la redéfinition d'éléments de niveau classe, j'utiliserai la seconde solution

Ah... ok.

Dans ton idée, ta classe aurait 2 responsabilités :

stocker les données (via les attributs d'instance)
decoder les données (via les methodes statiques)

Comme tu l'as suggéré, je trouve plus propre d'avoir 2 objets distincts pour les 2 responsabilités:

Code java :

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

1
2
3
4
5
 
interface Decoder<T> {
	boolean canDecode(String s);
	T decode(String s);
}

Code java :

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

1
2
3
4
5
 
class Decoder1 implements Decoder<Classe1> {
	public boolean canDecode(String s) { return true/false;	}
	public Classe1 decode(String s) { return new Classe1(x,y,z); }
}