Discussion :

[Chello]

Bonjour à tous,

J'ai une classe générale A et plusieurs classes AA, AB, AC, etc. toutes dérivées de A.

Je construit un objet "a" de classe A, qui est référencé dans une collection <extends A>.

Maintenant, l'objet "a" détermine lui-même s'il appartient à une classe dérivée AA, AB ou AC après inspection de ses propriétés.

Comment faire pour modifier la classe de a en AA, AB ou AC sans perdre l'objet dans la collection ?
En l'occurrence, je ne peux pas faire a = new AA(a), sinon il me crééerait un nouvel objet sans rapport avec le premier, sans compter que "this = new AA(a)" n'est pas permis.

Question je suppose simple, mais j'espère surtout qu'il y a une réponse que je n'ai pas trouvée.

Merci de votre aide,

[jcdentons]

Maintenant, l'objet "a" détermine lui-même s'il appartient à une classe dérivée AA, AB ou AC après inspection de ses propriétés.

Quel est le code pour la détermination de la classe ?
Si on fait un "setPropriété" suivi d'un "update" ou un truc du genre ...

[Chello]

Quel est le code pour la détermination de la classe ?
Si on fait un "setPropriété" suivi d'un "update" ou un truc du genre ...

La classe A comprends effectivement une fonction void setPropriete(), qui renseigne une variable de type enum.

Par exemple, lorsque j'instancie une classe Voiture, setPropriete() détecte s'il s'agit d'un cabriolet (Voiture.format = Format.CABRIOLET), d'un coupé (Voiture.format = Format.COUPE), d'un 4x4, etc.

Une fois que j'ai cette information, un update doit être réalisé, mais justement, je ne sais pas comment faire pour auto-modifier la classe A en une de ses dérivées, sans modifier la liste qui n'est pas accessible à partir de la classe Voiture.

Le truc serait évidemment de détecter le type de classe avant de stocker l'objet dans la liste, mais d'une part, le partage des tâches dans mon architecture m'incite à l'éviter, et d'autre part, c'est l'objet lui-même qui collecte les infos qui déterminent ensuite son type précis.

[Astartee]

J'ai une classe générale A et plusieurs classes AA, AB, AC, etc. toutes dérivées de A.
Je construit un objet "a" de classe A, qui est référencé dans une collection <extends A>.
Maintenant, l'objet "a" détermine lui-même s'il appartient à une classe dérivée AA, AB ou AC après inspection de ses propriétés.

Si ton objet a été créé comme instance de AA (A myA= new AA();), il est déjà de type AA, il n'y qu'à effectuer un cast au moment où l'on veut utiliser une méthode spécifique à AA (((AA)myA).methodeDeAA()).
Si ton objet a été créé comme instance de A (A myA= new A();), il est impossible de le "transformer" après coup en AA... Il faut définir le type de l'objet dès son instanciation.

En fonction du contexte de ton problème, tu peux peut-être utiliser le design pattern Factory: les objets ne sont pas instanciés par un appel direct au constructeur, mais via une méthode statique qui décide quel constructeur appeler :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class A
{
   public static A newInstance(/*arguments...*/)
   {
      if (/*test sur les arguments...*/) return new AA(/*arguments*/);
      else if (/*test sur les arguments...*/) return new AB(/*arguments*/);
      else if (/*test sur les arguments...*/) return new AC(/*arguments*/);
      // ...
   }
}

[Chello]

Si ton objet a été créé comme instance de AA (A myA= new AA();), il est déjà de type AA, il n'y qu'à effectuer un cast au moment où l'on veut utiliser une méthode spécifique à AA (((AA)myA).methodeDeAA()).
Si ton objet a été créé comme instance de A (A myA= new A();), il est impossible de le "transformer" après coup en AA... Il faut définir le type de l'objet dès son instanciation.

En fonction du contexte de ton problème, tu peux peut-être utiliser le design pattern Factory: les objets ne sont pas instanciés par un appel direct au constructeur, mais via une méthode statique qui décide quel constructeur appeler :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class A
{
   public static A newInstance(/*arguments...*/)
   {
      if (/*test sur les arguments...*/) return new AA(/*arguments*/);
      else if (/*test sur les arguments...*/) return new AB(/*arguments*/);
      else if (/*test sur les arguments...*/) return new AC(/*arguments*/);
      // ...
   }
}

Merci pour la réponse.

Le problème n'est pas le cast.

Malheureusement, la proposition n'arrange pas mes affaires. Le test sur les arguments est assez complexe, et dans l'option retenue, n'a pas à être effectuée lors de la première instanciation.

Je vais voir ce que je peux faire avec, mais si d'autres solutions émergent, je suis tout ouïe !

[jcdentons]

Est-ce vraiment nécessaire d'avoir plusieurs classes ? Une seule ne suffirait pas ?

[Chello]

Est-ce vraiment nécessaire d'avoir plusieurs classes ? Une seule ne suffirait pas ?

En l'occurence, non, car là s'arrête la comparaison avec des voitures : hormis des attributs et méthodes générales, les classes dérivées ont des méthodes de traitement qui n'ont rien à voir entre elles.

C'est comme si, en quelques sortes, on avait la classe générale "matière", qui se subdivise ensuite en plusieurs classes dérivées selon leur état liquide, solide, ou gazeux, et chacune serait utilisée pour calculer leurs résistances. Et c'est un peu plus compliqué encore car elles entretiennent des relations différenciées entre chacune d'elles.

C'est plutôt le regroupement en une classe qui pourrait interroger, mais il faut des collections pour un cache, le tri, etc.

[thelvin]

En l'occurrence, je ne peux pas faire a = new AA(a), sinon il me crééerait un nouvel objet sans rapport avec le premier, sans compter que "this = new AA(a)" n'est pas permis.

Et alors ? Ça ne t'empêche pas de faire comme ça quand même. Fondamentalement, il y avait sans doute moyen de mieux penser le code dès le départ, mais peu importe, rien n'empêche de construire un nouvel objet dans la bonne classe.

[jcdentons]

Et il ne serait pas plus simple de faire une classe unique contenant un objet de type A (la classe mère).

Ensuite, lors du setPropriete, on recrée l'objet de type AA, AB ou autre en fonction de ce setPropriete ?

[Chello]

Et alors ? Ça ne t'empêche pas de faire comme ça quand même. Fondamentalement, il y avait sans doute moyen de mieux penser le code dès le départ,

Sans doute, mais s'il n'y avait que cette contrainte...

mais peu importe, rien n'empêche de construire un nouvel objet dans la bonne classe.

À condition de mettre à jour la liste aussi, oui.

Et il ne serait pas plus simple de faire une classe unique contenant un objet de type A (la classe mère).

Ensuite, lors du setPropriete, on recrée l'objet de type AA, AB ou autre en fonction de ce setPropriete ?

C'est plus ou moins ainsi que je vais contourner, effectivement, en remettant à jour la liste.

J'imaginais et j'espérais qu'il était plus facile d'étendre une classe vers une de ses dérivées. Je vais effectivement créer un nouvel objet avec l'objet initial en argument.

Merci de vos réponses,

[rolfone]

bonjour,

Désolé mais il y a un truc que je ne comprend pas dans problème

si c'est ta class qui détermine d'elle même de qu'elle type elle est.

quand tu remplie t'a collection tu crée des objet de type A et c'est ce même A qui est capable de dire que c'est un AA ou un AB

pourquoi tu ne remplie pas directement t'a collection avec des AA et AB qui en plus hérite de A?

et après tu fait des simple cast.

pour faire ça tu te crée une methode static

Code :

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

1
2
3
public static A creatObject(_tes paramètres que tu utilise pour crée A_){
   //ton code pour déterminer la class fille 
}

et pour remplir ta collection

Code :

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

maCollection.add(A.creatObject(paramètres ));

pour finir quand tu veut utiliser une méthode spécial de AA

Code :

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

1
2
3
4
A myA = maCollection.get(12);
if(myA instenceof AA ){
   ((AA)myA).methodeAA();
}