Hello,

Je bute sur un problème. Je ne sais pas si c'est réalisable en java.

Voici mon problème.
J'ai une interface I, 2 classes A et B qui implémente cette interface.

public interface I {... }

public class A implements I {.... }
public class B implements I {.... }

Je voudrais savoir s'il est possible de faire ceci :

List<I> myList = new ArrayList<I>();

myList.add(new A());
myList.add(new B());

for (I i:myList) {
   ... uneMethode(i)
}

avec uneMethode qui aurait une implémentation pour la classe A et une autre pour la classe B, tout en étant dans des classes séparées de A et de B, pour séparer la partie métier du modèle.

En c++, ceci fonctionnerait (je crois)

C {
void uneMethode(A a) { ...}
void uneMethode(B B) { ...}

}

car il fait la résolution de dépendance au runtime (ou un truc du genre)

mais en java ça n'a pas l'air possible.

Y a t'il un mécanisme ou un design pattern pour faire ce que je veux ?

J'espère être clair.

Salut,

oups j'avais mal compris ton problème ...

En fait tu risques d'avoir un problème car tu ne connais pas la classe donc ta classe qui implemente uneMethode(i) devrai recevoir ton interface i en paramètre. car si tu fais un interface c'est pour implémente un comportement general. pour ceux que tu veux faire tu peux y arriver par réflexivité, mais en général il y a un autre moyen il faudrait que tu expose plus clairement la situation que avec des A et B :D. Si tu veux donnez plus d'info on pourra plus facilement trouver une meilleur architecture qui fait ce que tu veux.

Bonne chance

Citation : Ligarnes

si tu fais un interface c'est pour implémente un comportement general

Je dirais plutôt que c'est pour faire un contrat ...

je vais tenter de présenter le problème sous un autre angle.

Mes objets A et B sont des modèles. Les méthodes uneMethode sont des méthodes qui représentent les vues pour chaque type de classe.
Normalement, je devrais les mettre au niveau de mes objets A et B mais je veux séparer la vue des données.

Je pourrais faire comme ça mais c'est cracra

public class C {
	
	void test() {
		
		List<I> myList = new ArrayList<I>();
		myList.add(new A());
		myList.add(new B());
		
		
		
		for (I i:myList)
			if (i instanceof A) {
			     A a = (A)i;   
			     myMethod(a);
			   } else if (i instanceof B) {
			     B b = (B)i;   
			     myMethod(b);
			   }
		}
	
	void myMethod(A a) {
		
	}
	
	void myMethod(B b) {
		
	}

}

comment faire autrement ?

Citation : Bobza

comment faire autrement ?

En implémentant le modèle Observeur, voire le pattern MVC selon tes besoin.
=> http://www.siteduzero.com/tutoriel-3-6 [...] tern-mvc.html

pas besoin d'instanceof et de cast, le bon type est determiné au runtime

Citation : shakhal

pas besoin d'instanceof et de cast, le bon type est determiné au runtime

euh ...

eclipse me met The method myMethod(A) in the type C is not applicable for the arguments (I) pour le code suivant

public class C {
	
	void test() {
		
		List<I> myList = new ArrayList<I>();
		myList.add(new A());
		myList.add(new B());
		
		
		
		for (I i:myList)
			myMethod(i);
		}
	
	void myMethod(A a) {
		
	}
	
	void myMethod(B b) {
		
	}

}

sinon le lien sur le pattern MVC est intéressant mais un peu compliqué pour ce que je veux.
En fait j'ai trouvé une solution, mais ça pose d'autres problèmes ...

public interface VI {
	
	public void myMethode();

}

public class VA implements VI {

	private A a;
	
	public VA(A a) {
		this.a = a;
	}
	
	public void myMethode() {
	}
}
public class VB implements VI {

	private B b;
	
	public VB(B b) {
		this.b = b;
	}
	
	public void myMethode() {
	}
}
public class C {
	
	void test() {
		
		List<VI> myList = new ArrayList<VI>();
		myList.add(new VA(new A()));
		myList.add(new VB(new B()));
		
		
		
		for (VI i:myList)
			i.myMethode();
		}
}

Le problème c'est que je crée autant d'objet VA et VB que d'objet A et B, ce qui au niveau mémoire me pose problème car je suis susceptible d'avoir beaucoup d'objets A et B.
C'est pour ça que j'aurais préferré avoir un mécanisme qui propose une interface myMethode qui prenne des I d en paramètre

Citation : Bobza

Citation : shakhal

pas besoin d'instanceof et de cast, le bon type est determiné au runtime

euh ...

eclipse me met The method myMethod(A) in the type C is not applicable for the arguments (I) pour le code suivant

en effet, ça fonctionne pour les types avec héritage mais pas pour les types avec interface ou classe abstraite, mea culpa

Citation : shakhal

en effet, ça fonctionne pour les types avec héritage mais pas pour les types avec interface ou classe abstraite, mea culpa

Je croyais aussi.
Ta réponse m'a donné l'idée d'utiliser une classe abstraite à la place d'une interface

public abstract class I {
}
public class A extends I {
}
public class B extends I {
}

public class C {
	
	void test() {
		
		List<I> myList = new ArrayList<I>();
		myList.add(new A());
		myList.add(new B());
		
		
		for (I i:myList)
			myMethod(i);
		}
	
	void myMethod(A a) {
		
	}
	
	void myMethod(B b) {
		
	}

}

... mais ça ne marche pas non plus !

j'ai toujours l'erreur The method myMethod(A) in the type C is not applicable for the arguments (I)

le plus simple et de toute façon, le plus extensible reste de mettre myMethod dans I puis l'implémenter dans les classes concrètes

suffira de faire i.myMethod dans la boucle et a la rigueur, tu lui passe ce dont il a besoin dans C en paramètres() (mais pas C directement sinon couplage fort, et c'est mal).

Citation : shakhal

le plus simple et de toute façon, le plus extensible reste de mettre myMethod dans I puis l'implémenter dans les classes concrètes

suffira de faire i.myMethod dans la boucle et a la rigueur, tu lui passe ce dont il a besoin dans C en paramètres() (mais pas C directement sinon couplage fort, et c'est mal).

oui je sais bien, mais c'est ce que je voulais éviter, pour séparer simplement (sans une usine MVC) les données de la vue, pour faire en sorte que la vue soit dans une classe spécifique. Il s'agit d'une appli en 3d. La vue contient des fonctions openGl qui n'ont rien à voir avec les données ....

je développe un moteur de jeu, voilà comment je m'y suis pris:

public abstract class ClientEntity {

   private ClientVisualEntity graphic;

   public void setPosition(Vector3 pos) {
       this.graphic.setPosition(pos);
   }
}

Entity est le modèle, il contient toutes les données d'un objet jeu coté client, différentes suivant son implémentation.
ClientVisualEntity est la représentation visuelle de l'objet, ca peut être un objet 3d statique, movable, un objet 3d avec propriété physiques dynamiques,...
et on ne connait pas son implémentation(dans ce cas c'est Ogre pour la 3d et Bullet pour la physique)

Citation : shakhal

je développe un moteur de jeu, voilà comment je m'y suis pris:

public abstract class ClientEntity {

   private ClientVisualEntity graphic;

   public void setPosition(Vector3 pos) {
       this.graphic.setPosition(pos);
   }
}

Entity est le modèle, il contient toutes les données d'un objet jeu coté client, différentes suivant son implémentation.
ClientVisualEntity est la représentation visuelle de l'objet, ca peut être un objet 3d statique, movable, un objet 3d avec propriété physiques dynamiques,...
et on ne connait pas son implémentation(dans ce cas c'est Ogre pour la 3d et Bullet pour la physique)

donc si je comprends bien tu as autant d'objet (hérité de) ClientVisualEntity que de ClientEntity ? autrement dit, autant de vues que de modèle ?
Je voulais éviter ça, car grosso-modo la mémoire allouée est multiplié par 2.
Prends minecraft par exemple ; on utiliserait une vue différente pour chaque type de brique (au lieu d'avoir la texture en paramètre de l'objet, elle serait contenue dans la vue ; on aurait donc une implémentation de vue pour chaque type de brique). On serait obligé d'avoir autant d'objet vue que d'objet modèle -> quand tu voies le nombre de brique que peut contenir une scène, c'est embêtant de multiplier par 2 !

Dans l'absolu, ce que je voulais faire c'était créer 2 méthodes (static ou pas forcément) représentant 2 vues différentes, et passer le modèle en paramètre à la méthode associée à l'implémentation

Comme ceci quoi

public class C {
	
	void test() {
		
		List<I> myList = new ArrayList<I>();
		myList.add(new A());
		myList.add(new B());
		
		
		for (I i:myList)
			myMethod(i);
		}
	
	void myMethod(A a) {
		
	}
	
	void myMethod(B b) {
		
	}

}

ClientVisualEntity n'est pas une vue c'est une représentation visuelle qui fait partie d'une vue(par exemple GameView pour la représentation 3d, TacticView pour la représentation 2D)

seule cette représentation est consciente de faire partie de la vue, le ClientEntity est juste le modèle

Ok, si tu veux ... mais ça ne m'aide pas à résoudre mon problème

Pour le rappeler mon problème, il s'agit simplement de faire un truc propre à la place de

public class C {
    
    void test() {
        
        List<I> myList = new ArrayList<I>();
        myList.add(new A());
        myList.add(new B());
        
        
        
        for (I i:myList)
            if (i instanceof A) {
                 A a = (A)i;   
                 myMethod(a);
               } else if (i instanceof B) {
                 B b = (B)i;   
                 myMethod(b);
               }
        }
    
    void myMethod(A a) {
        
    }
    
    void myMethod(B b) {
        
    }

}

tu fais un observer et c'est reglé:

Model contient une liste de View

a chaque update du model: view.update(model.data)

je ne connaissais pas les observers
à priori je ne vois pas comment ça peut m'aider dans mon problème : update ou pas du modèle, la vue prend le modèle en paramètre ... les modèles n'ont rien à notifier aux vues ... mais bon je vais quand même réfléchir à la question.

Après débat avec mes collègues, je crois qu'il n'y a pas d'autres solutions "simple" que de faire une interface correspondant à la vue comme ceci

public interface VI {
    
    public void myMethode();

}

public class VA implements VI {

    private A a;
    
    public VA(A a) {
        this.a = a;
    }
    
    public void myMethode() {
    }
}
public class VB implements VI {

    private B b;
    
    public VB(B b) {
        this.b = b;
    }
    
    public void myMethode() {
    }
}
public class C {
    
    void test() {
        
        List<VI> myList = new ArrayList<VI>();
        myList.add(new VA(new A()));
        myList.add(new VB(new B()));
        
        
        
        for (VI i:myList)
            i.myMethode();
        }
}

mais j'en reviens toujours au même problème que je voulais éviter, à savoir que je crée autant de VA et de VB que de A et de B ...

non la vue ne prend pas le modele en parametre, surtout pas, elle prend des données:

un exemple simple:

la gui affiche le statut d'un vaisseau spatial:

la gui implémente une interface de mise a jour
le vaisseau contient une liste de ce type d'interface

public interface ShipViewer {
    update(int hull, int shield, int speed);
}

public class Gui implements ShipViewer {
    update(int hull, int shield, int speed) {
       hullLabel.print(hull);
       shielLabel.print(shield);
       speedLabel.print(speed);
    }
}

public class Ship {
    List<ShipViewer> viewerList;

    public void setSpeed(int speed) {
        ...
        for (ShipViewer sv : viewerList) {
            sv.update(this.hull, this.shield, this.speed);
        }
    }
}

maintenant je comprend mal ton probleme, decoupler la vue du modele signifie que le modele est indépendant de la vue, mais pas que la vue soit indépendante des données du modèle ca n'aurait pas de sens, il faut bien qu'on sache ce qu'on va afficher dans la vue.

Je crois qu'on a un problème avec les termes qu'on utilise ...

Citation : shakhal

maintenant je comprend mal ton probleme, decoupler la vue du modele signifie que le modele est indépendant de la vue, mais pas que la vue soit indépendante des données du modèle ca n'aurait pas de sens, il faut bien qu'on sache ce qu'on va afficher dans la vue.

Je suis bien d'accord avec ça ! Par contre je trouve que ça ne va pas du tout avec ton exemple :

public class Ship {
    List<ShipViewer> viewerList;

    public void setSpeed(int speed) {
        ...
        for (ShipViewer sv : viewerList) {
            sv.update(this.hull, this.shield, this.speed);
        }
    }
}

car "Ship" contient une liste de "ShipViewer" : donc, corrige moi si je me trompe, le modèle n'est pas indépendant de la vue. Le couplage est faible, car via une interface, mais il y a quand même un couplage.
Ton exemple me semble caduque car "ShipViewer" est en fait à la fois une vue (affichage des données) et un contrôleur (update des données) Non ?

Citation : Bobza

Je crois qu'on a un problème avec les termes qu'on utilise ...

Citation : shakhal

maintenant je comprend mal ton probleme, decoupler la vue du modele signifie que le modele est indépendant de la vue, mais pas que la vue soit indépendante des données du modèle ca n'aurait pas de sens, il faut bien qu'on sache ce qu'on va afficher dans la vue.

Je suis bien d'accord avec ça ! Par contre je trouve que ça ne va pas du tout avec ton exemple :

public class Ship {
    List<ShipViewer> viewerList;

    public void setSpeed(int speed) {
        ...
        for (ShipViewer sv : viewerList) {
            sv.update(this.hull, this.shield, this.speed);
        }
    }
}

car "Ship" contient une liste de "ShipViewer" : donc, corrige moi si je me trompe, le modèle n'est pas indépendant de la vue. Le couplage est faible, car via une interface, mais il y a quand même un couplage.
Ton exemple me semble caduque car "ShipViewer" est en fait à la fois une vue (affichage des données) et un contrôleur (update des données) Non ?

Le modèle contient une liste de truc a mettre a jour que ce soit une vue, un log, une DB, on s'en fiche, faut bien récupérer les données à mettre à jour depuis quelque part, l'oo c'est pas magique, maintenant si ça te dérange tant que ça, fait l'injection des données via de l'aop, c'est lourd mais découplé.

le contrôle des données se fait entre la vue et le modèle, donc juste avant le setSpeed(int) dans le cas que j'ai cité, tu peux aussi le faire directement dans le modèle mais alors tu auras répétition si tu as plusieurs implémentations d'un même modèle.

Citation : shakhal

Le modèle contient une liste de truc a mettre a jour que ce soit une vue, un log, une DB, on s'en fiche, faut bien récupérer les données à mettre à jour depuis quelque part, l'oo c'est pas magique, maintenant si ça te dérange tant que ça, fait l'injection des données via de l'aop, c'est lourd mais découplé.

On n'a pas la même conception du truc.
Pour moi la vue doit accéder aux données en lecture ; ce n'est pas aux données de faire l'update de la vue, ce serait plutôt au contrôleur. Le contrôleur dans ce cas chapeaute la vue et les modèles.
Mais bon, c'est simplement MA manière de faire hein je ne dis pas que ta méthode est mauvaise

Il n'y a pas de solution simple à ce problème qui me semblait basique. Donc laissons tomber.
Merci pour ton aide en tous cas

Dans ce cas, tu gardes la liste des vues dans le controlleur et tu les met a jour depuis cet endroit, avec des méthodes qui retournent le résultat dans le cas d'une modification depuis la logique applicative.

oui c'est plus ou moins comme ça que je fais

mais ce n'est pas ça le problème !!!!
relis le premier post, peut-être que tu comprendras mieux maintenant (sinon laisse tomber hahaha)

Citation

Pour le rappeler mon problème, il s'agit simplement de faire un truc propre à la place de

public class C {
    
    void test() {
        
        List<I> myList = new ArrayList<I>();
        myList.add(new A());
        myList.add(new B());
        
        
        
        for (I i:myList)
            if (i instanceof A) {
                 A a = (A)i;   
                 myMethod(a);
               } else if (i instanceof B) {
                 B b = (B)i;   
                 myMethod(b);
               }
        }
    
    void myMethod(A a) {
        
    }
    
    void myMethod(B b) {
        
    }

}

Ce code est mauvais, car tu es obligé d'ajouter un nouveau test et une nouvelle méthode à chaque fois que tu ajoutes une nouvelle implémentation de I.

Pourquoi ne pas opter pour la même chose mais en version dynamique ?
Je ne suis pas certain à 100% que ça va marcher, mais c'est à essayer !

public interface I { ... }
public class A implements I { ... }
public class B implements I { ... }
public interface Delegate<T extends I> {
public void myMethod  (T t) ;
}

public class C {
List<I> myList = new ArrayList<I>();
Map<Class,Delegate> delegates = new HashMap<Class,Delegate>();

public <T> void addDelegate (Class<T> cl, Delegate<T> d) {
delegates.put(cl,d);
}
public Delegate getDelegate (Class cl) {
Delegate d = delegates.get(cl);
if (d!=null)  return d;
else if (cl.getParent()!=null) return getDelegate(cl.getParent());
else throw new IllegalArgumentException("Type inconnu: " + cl);
}

public void test () {
for (I i : myList) {
getDelegate(i.getClass()).myMethod(i);
}}

}

Normalement ça doit marcher, avec peut-être quelques warnings. Si tu as beaucoup de spécialisations, la recherche de la bonne méthode se rapproche de O(1), sinon au pire ça sera récursif au plus autant de fois que la hauteur de l'arbre représentant ta hiérarchie de classes, donc normalement pas plus que 5 ou 6...

Citation : QuentinC 2

Ce code est mauvais, car tu es obligé d'ajouter un nouveau test et une nouvelle méthode à chaque fois que tu ajoutes une nouvelle implémentation de I.

Voilààààààààà !!! enfin un qui a compris !!!

je suis pas sûr de tout comprendre ton code ; je ne maitrise pas les génériques ; mais je vais étudier ça

merci

En fait ça s'appelle du double dispatch.

http://accu.org/index.php/journals/496
http://en.wikipedia.org/wiki/Multiple_dispatch

Mon code avait de l'idée, mais j'ai oublié quelque chose d'important: ma moulinette ne fait plus la différence selon l'objet de départ !

Je viens de découvrir le design pattern decorator et je me demande si il ne correspond pas à ce que je cherche à faire ...

Sinon tu utilise Visitor :

public interface I extends Visitable{}

public interface Visitable{
     public void accept(Visitor visitor);
}

public interface Visitor{
      public void visitA(A a);
      public void visitB(B b);
}


public class VisitorUneMethode implements Visitor{
    public void visitA(){
        // Le code uneMethode() pour A
    }

    public void visitB(){
          // Le code uneMethode() pour B
    }
}


public class A implements I{
   public void accept(Visitor visitor){
        visitor.visitA(this);
   }
   // ..... reste de A
}

public class B implements I{
    public void accept(Visitor visitor){
          visitor.visitB(this);
    }
    // ..... reste de B
}

Avantages :
Finalement il y'a pas de cast, de instanceof, et toutes ces choses pas terrible
Pour ajouter une nouvelle methode (de type "uneMethode(I i)") tu a juste à créer un nouveau visitor

Inconvénients :
Un peu intrusif sur tes objets A et B (tu ajoute un traitement n'ayant aucun rapport direct avec leur nature)
Dès que tu veux introduire un nouveau Visitable tu doit recoder tout tes Visitors.

Visitor est très bien décrit sur Wikipedia

Decorator est plutôt adapté pour ajouter des traitements à une opération qui existe sans modifier du code.