Bonjour,

Je suis confront� a un probl�me de polymorphisme, et a chaques fois que je trouve une solution �a apporterait d'autres probl�mes alors je fais appel � vous.

Voila j'ai 3 classes :
employe,
membre (d�riv� d'employ�),
utilisateur (d�riv� de membre)

Ces classes sont persistantes, et suivent le m�me mod�le au niveau de la base de donn�es.

Chaque classe poss�de les m�thodes suivantes :
toEmploye(),
toMembre(),
toUtilisateur().

Des instances de ces trois types diff�rents sont stock�es dans une collection.

Ce mod�le me permet a partir d'un indice dans la collection, de basculer d'un type a l'autre de mani�re tr�s transparente. de ce fait, je n'ai pas a connaitre le type d'origine, je sais que la conversion sera faite sans probl�mes.

Ainsi si un utilisateur dois devenir utilisateur, il se mettra simplement � jour (avec les valeurs en param�tre ici non pr�sentes).

Avec ce mod�le il est clair qu'un utilisateur dois imp�rativement �tre avant tout membre.
Voici donc un cas d'utilisation :
Un employ� est s�lectionne, puis on veux le transformer en utilisateur, il se passe donc :
1/ on transforme d'abord en membre, afin de r�cup�rer une partie des nouvelles informations sp�cifiques a membre.
2/ on transforme en utilisateur avec les derni�re informations.

Maintenant on part du principe qu'un utilisateur est s�lectionne :
1/ on converti en membre, donc perte de l'information en d�truisant son num de la table utilisateur.
2/ Etant donn� que c'est un utilisateur et qu'on lui demande d'en devenir un, il se mettra simplement a jour, et tentera de se modifier en base, alors qu'il viens de se supprimer.

LA solution qui r�soudrait tout serait d'�viter une appel de modification vers autres membre quand on est utilisateur, seulement dans ce cas, si on reprend l'exemple num�ro un, utilisateur ne sera plus transform� en membre avant de devenir utilisateur, donc ca coincerais a ce niveau la.

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
 
            switch(cbTypePersChoix->SelectedIndex)
            {
            case 0:
                ((employes^)objGestListe::listEmployes[lbPers->SelectedIndex])->toTechniciens();
                break;
            case 1:
                ((employes^)objGestListe::listEmployes[lbPers->SelectedIndex])->toJardiniers();
                break;
            case 2:
                //Si en plus c'est un user alors on complète
                ((employes^)objGestListe::listEmployes[lbPers->SelectedIndex])->toAutresMembres(newStatut);
                if(chbUser->Checked)
                {
                    ((employes^)objGestListe::listEmployes[lbPers->SelectedIndex])->toUtilisateurs(txtPersIdent->Text, txtPersPass->Text);
                }
 
 
                break;
            }
Ici la solution serait de pouvoir savoir si l'objet sur lequel on agi est de type utilisateur, et ne pas appeler la conversion vers Membre, mais dans ce cas je perd en partie l'avantage de la polymorphie.
Si l'un de vous � une id�e.

Je sais pas si j'ai post� au bon endroit (j'aurais peut-�tre du poser dans conception), si il n'est pas a la bonne place, qu'un mod�rateur n'h�site pas a le d�placer.