Discussion :

[Le prophete]

Bonjour,

J'aimerais savoir s'il est possible de sous-caster un objet autrement qu'en codant en dur le sous-castage, càd que j'aimerais éviter :

Code :

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

1
2
3
4
5
 
C obj;
if(A.class.isInstance(obj) {
methode((A)obj);
}

Je préfèrerais récupérer dynamiquement le type de obj qui m'intéresse (via une méthode quelconque ce cette classe) et le sous caster avec ce type. J'espère que je suis assez compréhensible

Merci d'avance

[thibaut]

Caster de façon dynamique une class est impossible, où alors je ne connais pas la méthode... mais pourtant j'ai cherché... Donc il te faut une autre solution...

[Le prophete]

Oki, merci. Du coup, autre question (toujours dans le même style) :

Pour être plus précis je manipule des objets de type ElectornicElement (qui est une interface). Cette interface est étendue par trois classes :
- une classe Connection.
- une classe Junction.
- une classe ElectronicComponent (abstraite). Cette dernière est étendue par une multitude de composants mais le type qui m'intéresse est bien ElectronicComponent.

Alors voilà ce à quoi j'ai pensé, mais ça m'a l'air très sale :
Je crée une méthode dans la classe ElectronicComponent qui me retourne forcément un ElectronicComponent.class, quel que soit le type de composant (un peu façon getClass, mais je veux pas la classe d'implémentation), pour Junction et Connection getClass fera l'affaire.

Ensuite je fais une HashMap dont les clés sont les objets class, et les valeurs des méthodes, ces méthodes se chargeant toutes seules de faire le sous-casting. La jour où je rajoute une classe implémentant ElectronicElement, il suffit de rajouter une entrée dans la HashMap. Le problème, c'est que je me demande si c'est pas encore plus laid que les tests pour déterminer la classe..... :

[tileffeleauzed]

En général, ce genre de préocupations est un indice de situations douteuses qui peuvent être élégamment résolues par le pattern du visiteur. Je m'étonne de ne pas l'avoir trouvé à la page des design pattern de developpez.com, je suis persuadé l'y avoir déjà vu. Comme quoi, on se fait des idées...

Bref, le principe de ce pattern et qu'il y a un deux objets qui se rencontrent et qui se font coucou !, mais comme ils sont pas pareils, alors ils se font pas coucou de la même manière... Je sais pas si je suis clair, alors allons-y pour le code...

Soit une opération O qui dépend du type d'objet passé en paramètre. Tu ne veux pas faire le cast au niveau de l'appel de méthode, parce que tu trouves que c'est pas du tout élégant. Alors tu lui passes un objet relais, qui rappelle l'objet émetteur, en faisant le cast sans que personne ne s'en aperçoive... n'est-ce pas génial ??

Soit l'objet qui fait l'opération :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
public class A
{
 ... quelque part :
  Visiteur a;
  a = ...;
  a.visitePourO(this);
}
 
// première possibilité d'opération O :
void O(Classe1 x)
{
 ...
}
 
// deuxième :
void O(Classe2 y)
{
 ...
}

Classe1 et Classe2 sont des héritiers de la classe Visiteur.

Dans Classe1, par exemple, la méthode :

Code :

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

1
2
3
4
5
6
 
 
public void visitePourO(A acteur)
{
 acteur.O(this); // -> ici j'irai à la première opération ; si j'avais été dans Classe2, j'aurais été à la deuxième.
}

Pareil pour Classe2 et, bien sûr, la classe Visiteur.

Suis-je clair ?? Vois-tu bien que le cast se fait sans aucun cast, ni downcast, ni souscast ???

[Le prophete]

Salut,

Bon après examen du pattern visiteur, je pense que c'est tout à fait ce qu'il me faut, moyennant une ch'tite adaptation (dans mon cas, mes composants électroniques comportent tous les mêmes méthodes, donc j'ai pas besoin de plusieurs visiteurs, un seul suffira).

Bon en tout cas