Interface générique : désigner la classe implémentant

Salut,

Je cherche le moyen de désigner la classe implémentant mon interface générique pour pouvoir l'utiliser dans mes signatures de méthodes. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9

package test;   public interface MonInterface<classe_implémentant> { public classe_implémentant getMonContenu();   public void setMonContenu(classe_implémentant); }

---

Une idée ?

Salut,
Remplace classe_implementant par T
Regarde du côté des Generics! ;)

Bonjour,

je ne suis pas sûr d'avoir compris ton besoin. Une implémentation de ton interface devrait ressembler à ça: ?

Code:

---

1 2 3 4 5 6 7 8 9

public class MonImplementation implements MonInterface<MonImplementation> { public MonImplementation getMonContenu() { ??? } public void setMonContenu(MonImplementation param) { ??? } }

---

Quel intérêt cela pourrait avoir pour une implémentation d'avoir en champ une instance d'elle-même?

Comme ceci :

Code:

---

1 2 3 4 5 6 7

public interface MonInterface<T extends MonInterface<T>> { public T getMonContenu();   public void setMonContenu(T t); }

---

Merci pour vos réponses.

Peu importe la raison, il est juste nécessaire qu'une classe implémentant mon interface ait une référence sur un objet de la même classe.

Le problème en indiquant T comme paramètre est que je peux avoir n'importe quel type. Voici plus exacement ce que je souhaiterai avoir :

Interface

Code:

---

1 2 3 4 5 6 7 8 9

package test;   public interface MonInterface<T super classe_implémentant> { public T getMonContenu();   public void setMonContenu(T t); }

---

Implémentation

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class MonImplementation extends UneSuperClasseQuelconque implements MonInterface<UneSuperClasseQuelconque> { public UneSuperClasseQuelcoonque getMonContenu() { //TODO }   public void setMonContenu(UneSuperClasseQuelconque uscq) { //TODO } }

---

Si je voulais être statique avec le générique MonInterface, je pourrais mettre MonInterface à la place de classe_implémentant. Sauf que le problème est que je veux être dynamique sur ce point.

J'espère avoir été plus clair cette fois.

La réponse que j'ai donnée ne convient pas ? C'est précisément ce qu'il faut écrire pour induire une dépendance du paramètre générique sur l'interface ou la classe générique elle-même.

Citation:

---

Envoyé par herve91

La réponse que j'ai donnée ne convient pas ? C'est précisément ce qu'il faut écrire pour induire une dépendance du paramètre générique sur l'interface ou la classe générique elle-même.

---

Désolé j'ai rédigé ma réponse pendant que tu as posté la tienne.

Ta solution me permettra d'avoir n'importe quel contenu tant que celui-ci implémente l'interface MonInterface. Or je veux que le contenu soit du type de la classe implémentant (ou un super type, cf mon deuxième exemple de code).

En fait j'espérais qu'il-y-ait un mot clef ou une astuce quelconque permettant de désigner la classe implémentant.

À ma connaissance il n'y à pas moyen de distinguer interface ou classe. Par contre je ne vois pas l'intérêt de préciser une classe d'implémentation plutôt que l'interface... C'est vouloir imposer une contrainte là où il n'y en a pas. Il est toujours préférable de désigner une interface plutôt qu'une classe concrète.

Citation:

---

Envoyé par le2tbomi

Peu importe la raison

---

Je ne suis pas tout à fait d'accord, ma question n'était pas anodine.

En mettant des Generics un peu partout, on peut se retrouver piégé.
Je ne dis pas que c'est le cas de ton problème, mais il y a des cas où à force de mettre des Generics, on finit par caster avec des classes génériques, ce qui ne veut pas dire grand chose, vu que le cast est fait à l'exécution...

Il ne faut pas perdre à l'esprit que les Generics servent à éviter des erreurs de compilation.

C'est pourquoi je voulais en savoir plus sur les raisons des contraintes que tu as exprimé. Il se peut qu'en creusant un peu, on puisse trouver une solution dans une autre direction mais qui te conviennes aussi bien.

PS: et y'a aussi le fait que je suis curieux de nature ;)

Ok pour vos remarques. Voici donc la problématique en détail.

Je cherche à construire une interface représentant un nœud. L'interface s'appellerait donc Node (plus haut désignée par MonInterface). Cette interface décrit les méthodes permettant d'ajouter des sous nœud ainsi que des feuilles.

L'exemple le plus concret que je puisse trouver est un système de fichier : le nœud dossier contient des sous dossiers et des fichiers. De plus, si on exclue les représentations logiques, il n'est pas question qu'un dossier ne contienne autre chose que des sous-nœuds dossier et des feuilles fichier.

J'en ai déduit l'interface suivante pour mon Node :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public interface Node<T super classe_implementant, Content> { //Ci dessous les méthodes gérant la collection de sous-nœuds public void addNode(T node);   public void removeNode(T node);   public Collection<T> getNodes();   public void setNodes(Collection<T> nodes);   //Ci dessous les méthodes gérant la collection de feuilles public void addContent(Content content);   public void removeContent(Content content);   public Collection<Content> getContents();   public void setContents(Collection<Content> content); }

---

Pour en revenir à mon exemple, étant donné qu'il n'est pas question que mon dossier comporte autre chose que des sous-nœuds dossier, je dois restreindre l'utilisation des méthodes add, remove get et set des sous-nœuds avec la classe implémentant (ou au pire l'un de ses super types).

Voila pourquoi je souhaiterai avoir une signature telle que celle-ci pour mon interface.

En fins connaisseurs, vous remarquerez que cette interface fait largement penser au design pattern Composite, en restreignant son utilisation.

La solution la plus simple serait de déclarer une classe implémentant de cette manière :

Code:

---

1 2 3 4 5

public class MaClasse implements Node<MaClasse, String> { //TODO }

---

Sauf que cette déclaration ne me convient pas car il revient à la responsabilité du développeur utilisant l'interface que le contrat de l'utilisation de l'interface Node soit respecté. Ceci va à l'encontre de l'utilisation d'interface qui permet de déléguer cette responsabilité au compilateur (en quelque sorte).

Merci pour l'intérêt que vous montrez à mon problème.

C'est étrange, je me suis plongé dans un problème très proche il y a moins d'un mois...

Code:

---

public interface Node<T super classe_implementant, Content>

---

ce 'super' me gène, il laisserai mettre des objets qui ne sont pas des Nodes (Object par exemple).

Après, il semble que tu souhaites imposer des contraintes fortes à celui qui réalise l'implémentation de ton interface.
Sauf erreur de ma part, tu ne pourras pas faire mieux que :

Code:

---

public interface Node<T extends Node, Content>

---

Cela laissera évidemment la possibilité de déclarer :

Code:

---

public class MaClasse implements Node<Node, String>

---

et d'ajouter des nodes de type différent.

Ceci dit, s'il fait cela, il perdra la connaissance que ses Fils seront des 'MaClasse' et sera obligé de les caster en 'MaClasse' (ou autre)...

Effectivement, plus j'y réfléchis, et plus je pense que ce super n'est pas du meilleur goût. Il serait sans doute préférable d'utiliser un extends.

La solution que tu me propose est effectivement réalisable mais nous sommes d'accord pour dire qu'il ne s'agit pas d'une solution "secure".

Cela étant, si il n'y a que cette solution ...

J'aimerais néanmoins avoir plus d'avis, bien que ceux que j'ai eu sont tout à fait pertinents.

Je n'arrive toujours pas à comprendre pourquoi le code suivant ne conviendrait pas :

Code:

---

1 2 3 4 5 6 7 8 9 10

public interface Node<Content, T extends Node<Content, T>> { public void addNode(T node); }   public class Dossier implements Node<String, Dossier> { public void addNode(Dossier dossier) { ... } }

---

Tu ne peux pas ajouter à un Dossier autre chose que des Dossiers...

En fait, si j'ai bien compris, il aimerait contraindre celui qui écrit l'implémentation à écrire :

Code:

---

public class Dossier implements Node<String, Dossier> {

---

plutôt que ça:

Code:

---

public class Dossier implements Node<String, AutreClasse> {

---

qui lui donnerait la possibilité d'avoir des fils qui ne sont pas du même type que le père.

Après, à part en écrivant lui-même l'implémentation, je ne vois pas comment c'est possible.

C'est tout à fait cela.

L'autre possibilité est que ce problème n'a jamais été posé car l'idée (de restreindre le type de l'interface avec la classe implémentant) est tout simplement mauvaise et que je me trompe dans la modélisation.

Citation:

---

Envoyé par le2tbomi

C'est tout à fait cela.

L'autre possibilité est que ce problème n'a jamais été posé car l'idée (de restreindre le type de l'interface avec la classe implémentant) est tout simplement mauvaise et que je me trompe dans la modélisation.

---

La solution de Herve est tout a fait valide, et me semble la meilleure. Cette idée s'est déjà posée et est loind'être idiote. Lift, fait un usage intensif de ce genre de typage pour son framework de persistence. Les Mappers sont typés ainsi

Code:

---

1 2	trait Mapper[A<:Mapper[A]]

---

Ceci dit, il ne me parait pas vraiment possible d'obliger une sous classe, à paramétrer avec elle même. La solution de herve oblige au moins à paramétrer avec une classe qui a la hierarchie voulue (i.e. qui implémente l'interface paramétrée par elle même). Le risque couru est que l'implémentation fasse ça :

Code:

---

1 2 3 4

public interface Node<Content, T extends Node<Content, T>> { ... } public class Fichier implements Node<String, Fichier> { ... } public class Dossier implements Node<String, Fichier> { ... }

---

Fichier respecte le contrat mais on ne peut pas obliger Dossier à ne pas utiliser Fichier pour le paramétrage. Ceci dit, ça reste le plus sûr (et utilisé !)

Merci pour cette comparaison avec Lift (dont j'en ai appris l'existence par la même occasion).

Ton avis éclairé me laisse de plus en plus penser que je suis face à une limitation du langage et que je n'aurais effectivement pas le choix. Je pense donc déclarer l'interface :

Code:

---

public interface Node<Content, T extends Node<Content, T>> { ... }

---

Ou quelque chose d'approchant...

Je ne marque pas encore le thread comme résolu afin d'avoir (peut-être) encore quelques avis.

J'ai peut-être une solution qui s'éloigne de ton approche initiale.
Reste à voir si cela peut aller avec ton besoin au pas.

Tu manipules des noeuds (qui forment donc un arbre) qui doivent tous être du même type.

Pourquoi ne pas passer par un objet Tree, proche du TreeModel mais qui impose le type des noeuds. Ton Tree<T, C> ne contiendrait que des noeuds du même type : T (avec du contenu C).

Code:

---

1 2 3 4 5 6 7 8 9

public interface Tree<T, C> { T getRoot();   List<T> getChildren(T node);   List<C> getContent(T node);   ... }

---

Bien sûr, il existe des variantes avec "T extends Node" où tu pourrais modifier/retirer certaines méthode du Tree.

L'idée étant d'imposer le type à l'ensemble de l'arbre via un objet arbre "matérialisé", plutôt que de l'imposer à chaque noeud.

Il est certain qu'un conteneur de ce type pourrait vérifier la cohérence des Node. Il était d'ailleurs prévu dans notre modélisation d'avoir un objet de ce "type".

Cela ne résout pas le problème initial (qui est d'empêcher l'implémentation de typer le Node avec autre chose que lui même), mais apporte sans doute une solution alternative ;)

Je ne pensais même pas à des contrôles dans le Tree, la compilation devrait s'en charger, grâce à une méthode "add" typée par exemple.

En fait, j'ai l'impression que tu voudrais un peu plus que ce que j'avais compris. Tu aimerais un truc du genre:

Code:

---

public interface Tree<T where T is final> {...}

---

Non non, nous sommes d'accord sur le contrôle par la compilation et non par test de type dans le code.

Ce que j'entendais par cohérence des données, c'est vérifier qu'une implémentation déclare bien :

Code:

---

public class Dossier implements Node<Dossier, Fichier>

---

et non (par exemple) :

Code:

---

public class Dossier implements Node<String, Fichier>

---

en déclarant le Tree ainsi :

Code:

---

public class Tree<T extends Node<T, ?>>

---

Nous sommes d'accord ?

Citation:

---

Envoyé par le2tbomi

Nous sommes d'accord ?

---

Je pense oui.

Mais la vrai question est: est-ce que cela te convient? ;)

Dans l'absolu cette solution peut convenir, mais elle ne répond pas à l'intitulé du thread ;)

Interface générique : désigner la classe implémentant