Instance d'une classe avec une string

Bonjours à tous,

Je souhaiterais instancier l'objet d'une classe dont le nom serait connu uniquement dans une variable string...

Je sait que ce problème a déja été traité maintes fois sur ce forum ou même partout ailleurs.

Malheureusement, j'ai eu quelques difficultés en ce qui concerne l'interprétation, voire la compréhension des info que j'ai pu recueillir sur le sujet !

Je vais clairement expliquer le but de la manoeuvre, à présent...

--> Dans un programme C#(mode console), je dispose des classes suivantes:
1 - classe program : qui contient les méthodes (actions: lister, ajouter, miodifier, etc...) communes à tout cas d'utilisation !
2 - classe mère "Article" : c'est la classe mère qui possède des méthodes et des attributs commun à toutes les classes fille !
3 - plusieurs classes filles telle que "ArticleAcheté" : ces classes possèdes des attributs et méthodes qui leur sont spécifiques, et peuvent évidement accéder aux attributs et méthodes(virtual-override) commun de la classe mère...

Sachant, que les actions (méthodes : lister, ajouter, modifier, etc...), se trouve dans la classe Program, voici l'exemple précis de mon cas d'utilisation:
--> pour la fonction Lister :

Code:

---

1 2 3 4 5 6

string nomClass = "ArticleAcheté"; static public void LISTER (string nomClass) { nomClass toto = new nomClass(); .... }

---

Dans cet exemple, l'objet nouvellement crée "toto", devrait se voir appliquer les méthodes et attributs de la classe fille "ArticleAcheté"...
Cependant, mon exemple est faux : en effet, on ne peut pas instancier un objet directement avec une variable string !

Par conséquent, je recherche actuellement le moyen de créer l'objet dit "toto", a partir de la variable string "nomClass", laquelle contient le nom de la classe à instancier pour l'objet "toto" !

De cette manière, l'objet "toto" devrait se voir affecter tout les attributs et méthodes de la classe fille "ArticleAcheté"...

--> Exemple : Si la classe fille "ArticleAcheté" possède des méthodes spécifiques telles ques : afficher(), saisir(), getFournisseur(), etc...
Alors, on pourrait faire ceci :

Code:

---

1 2 3

toto.afficher(); toto.saisir(); toto.getFournisseur();

---

Voila, j'espere avoir été le plus explicite possible...

Je reste dès à présent ouvert à toutes suggestions...

Je vous remercie par avance, pour toute l'aide que vous pourrez m'apporter...

Oula, tu te compliques la vie :)
Etant donné que dans ta méthode "Lister", tu veux utiliser des méthodes propres à ton objet "ArticleAcheté", elle est fortement lié à cette classe ; tu peux faire directement

Code:

---

1 2 3 4 5

public void ListerArticleAcheté() { ArticleAcheté toto = new ArticleAcheté(); toto. }

---

Tu vois ce que je veux dire ? pourquoi tu veux rendre générique une méthode, alors qu'elle ne manipulera qu'un seul type d'objet ?

Sinon, connais-tu les generics ? Ca permet de paramétrer une méthode par type, c'est très puissant, joli, et tout :)

En fait, si je procéde comme l'extrait de code, je suis obligé de nommé explicitement la classe (ArticleAcheté), pour laquelle mon objet va être instancié...

Mais je dispose de nombreuses classes filles, il n'y a pas que la classe fille "ArticleAcheté" en fait...

Par conséquent, cela voudrait dire qu'il y aurait autant d'objet à instancier que de classe fille, et le code de la méthode Lister (dans mon exemple), devrait être recopier autant de fois qu'il y aurait d'objet différent...
Imagine le rendu dans une architecture de type Framework !!

Je veux simplement rendre les éléments plus modulaire et indépendant, en instanciant un objet, pour une classe donnée à partir de son nom (lequel est fournie uniquement dans une variable string, passé en paramètre à la méthode appelante)

Autre bémol, la méthode ne peut pas s'appeler "ListerArticleAcheté", étant donné qu'elle ne listera pas que des éléments de la classe "ArticleAcheté", mais de toutes les classes filles !

Citation:

---

Envoyé par beetlejuice722

Dans cet exemple, l'objet nouvellement crée "toto", devrait se voir appliquer les méthodes et attributs de la classe fille "ArticleAcheté"...

---

Donc t'es bien d'accord que dans méthode Lister, tu vas appeler des méthodes propres à ArticleAcheté ?

Sinon, comme je te disais, les generics devraient satisfare ton besoin :

Code:

---

1 2 3 4 5 6

public static void Lister<T>() where T : Article, new() { T toto = new T(); // possible grâce à la contrainte new() sur le type T toto.afficher(); // possible grâce à la contrainte d'héritage sur T ... }

---

Je suis tout à fait d'accord avec ton exemple...

Je l'ai testé, mais avec cette manière l'objet toto, n'aurait pas accès aux attributs et méthodes spécifiques des classes fille, telle que "getFournisseur()" pour la classe fille "ArticleAcheté" !

N'y a t-il pas un moyen pour passé en paramètre la classe à instancier (Article dans ton exemple), sans qu'elle soit désigné explicitement ?

quelque chose comme :

Code:

---

1 2 3 4 5 6 7 8

string maClasseFille = "ArticleAcheté"; // Ou n'importe quel autre nom de classe fille : il n'y a pas que "ArticleAcheté" public static void Lister<T>() where T : maClasseFille, new() { T toto = new T(); // possible grâce à la contrainte new() sur le type T toto.getFournisseur(); // appel d'une méthode spécifique à une classe fille ... }

---

En tout cas, je te remercie de m'aider dans mon problème ! :P

Je reprends ce que je disais tout à l'heure.

Tu veux appeler des méthodes propres à la classe fille dans Lister. Donc t'es bien d'accord que Lister est "propre" à ta classe fille ? Que tu vas toujours l'appeler comme ça : Lister("ArticleAcheté"), puisque sinon tu pourras pas appeler getFournisseur, puisque sinon ton toto sera autre chose qu'un ArticleAcheté ?

Non ce n'est pas ca...

Tout est dans le "sinon" que tu exprimé, à savoir :

1 - mon "toto" peut être autre chose qu'un ArticleAcheté : par exemple il peut être un ArticleEpuisé, élément d'une autre classe fille "ArticleEpuisé" !

2 - Je ne l'appelerais pas comme cela :
Lister("ArticleAcheté")
mais plutot comme cela :
string nomClasseFille = "nom_de_nimporte_quel_classe_fille"
Lister(nomClasseFille)

la variable string "nomClasseFille", peut prendre des valeurs différentes : "ArticleAcheté", "ArticleEpuisé", et autant d'autre valeur(ou nom) qu'il y aura de classe fille !

Mais dans tout les cas, la variable string (nomclassefille), sera initialisée au nom de la classe appelante de la methode Lister !

Pour être plus précis, voila le déroulement des evenements :
1- Je veut agir (ou gérer) des article épuisé, donc mon menu général (le main), me renvoi vers un sous-menu : celui de la classe fille "ArticleEpuisé"
2 - Une fois dans ce sous-menu, je peut par exemple lister mes articles épuisé
: par conséquent, mon sous menu (classe ArticleEpuisé) appele la méthode générique Lister (qui se trouve dans la classe Program)...
3 - Mais lorsque j'appele la méthode lister, je lui passe en paramètre une string nommé nomClasse, laquelle est initialisé à "ArticleEpuisé", puiske je suis dans la classe ArticleEpuisé...
Cela veut dire que si on était dans la classe "ArticleAcheté", il y aurait aussi une variable string nomClasse, mais qui serait initialisée à "ArticleAcheté", puis on listerait des ArticleAcheté...

Pour éviter toutes confusion, voici quelques extraits de codes, à titre indicatif :
Je suis dans la classefille "ArticleEpuisé", au niveau du sous menu qui permet la gestion des article épuisé :

Code:

---

1 2 3

string nomClasse = "ArticleEpuisé"; //J'appel ici la améthode lister de la classe program, afin de lister (dans ce //cas précis) des article épuisé Program.lister(nomClasse)

---

Maintenand, nous voici dans la classe program (qui repertorie les methodes génériques telle que lister, ajouter, rechercher, etc...) :

Code:

---

1 2 3 4

static public lister (string nomClasse) // Donc, dans la variable nomClasse , on récupère le nom de la classe fille appelante //de notre méthode lister { }

---

De cette manière, on doit pouvoir lister aussi bien des article acheté que des article épuisé de facon tout à fait indépendante...

Ma problématique réside dans le fait de créer un objet dont le type (celui de la classe fille qui appèle la methode lister) serait uniquement connu à travers la variable string nomClass...

Une fois de plus, merci pour toute l'aide que tu m'apporte...;)

il est possible de créer une instance à partir du nom de la classe as string avec la fonction CreateInstance

Citation:

---

Envoyé par sperot51

il est possible de créer une instance à partir du nom de la classe as string avec la fonction CreateInstance

---

Non, pitié, pas de réflexion quand ça sert à rien :aie:

Pourquoi absolument passer par des chaînes ? Selon ton menu, tu appelleras Lister<Bidule>() ou Lister<Truc>(). Passer par des chaînes de caractère ne sert à rien.

j'ai pas lu exactement ce qu'il voulait, je répondais juste à la question du titre ^^

mais la reflection c'est très pratique, et c'est pas lent tant qu'on ne fait des boucles qui font de la reflection dans tous les sens

Pour répondre au 1er message de sperot51 :
Je connais cette fonction, mais dans la pratique, je ne suis pas encore parvenu à la mettre en place !

Voici ce que j'avais fait avec cette fonction, par rapport à mon exemple :

Code:

---

1 2 3 4 5 6 7 8

// Admettons quon liste des article épuisé, //on aurait alors quelque chose comme : string nomClasse = "ArticleEpuisé"; static public void lister(string nomClasse) { Type z = Type.GetType(nomClasse); object toto = Activator.CreateInstance(z); }

---

Mais dans ce cas précis, l'objet toto n'hérite pas des attributs et méthodes spécifiques de la classe fille "ArticleEpuisé"...
En effet, on ne peut pas faire : toto.getNomArticleEpuisé()

En revanche, cela marche, si l'on procéde comme suit :

Code:

---

1 2 3 4 5 6

string nomClasse = "ArticleEpuisé"; static public void lister(string nomClasse) { Type z = Type.GetType(nomClasse); ArticleAcheté toto = (ArticleAcheté)Activator.CreateInstance(z); }

---

Mais ce deuxième procédé est inutile dans mon cas d'utilisation, puisque la classe fille "ArticleAcheté" est explicitement désignée lors de la création de l'objet toto...

N'y aurait-il pas une autre manière de faire, sans pour autant nommer explicitement la classe fille, dans la méthode lister ?

Citation:

---

Envoyé par sperot51

j'ai pas lu exactement ce qu'il voulait, je répondais juste à la question du titre ^^

mais la reflection c'est très pratique, et c'est pas lent tant qu'on ne fait des boucles qui font de la reflection dans tous les sens

---

Je sais je sais :) Mais comme ça se place en dehors d'une modélisation objet "propre", je pense qu'il ne faut s'en servir que si nécessaire. Surtout quand il n'y a pas de binding, ni de sérialisation, etc. Et si on en dépend trop, un changement de nom de classe (par exemple) risque de plus marcher, le compilo n'étant pas capable statiquement de savoir si un bout de code avec de la réflexion de partout pètera ou pas.

dans le code que tu mets, tu utilises createinstance avec un type, moi je dis que c'est faisable avec un string

enfin je comprends pas trop ton soucis, cherche des infos sur le design pattern factory, peut etre que c'est ca qu'il te faut

La solution de Guulh m'a l'air intéressante, mais je reste septique en ce qui concerne le <Bidule> ou le <Truc>

Pour reprendre ton exemple de tout à l'air tu m'a suggérer cela :

Code:

---

1 2 3 4 5 6

public static void Lister<T>() where T : Article, new() { T toto = new T(); // possible grâce à la contrainte new() sur le type T toto.afficher(); // possible grâce à la contrainte d'héritage sur T ... }

---

dans cet exemple tu indique que le <T> est de type "Article", afin de travailler sur les éléments de la classe Article (classe mère)...

Ma question est: Ce fameux <T>, peut-il être paramètré en amont de le fonction Lister, c'est à dire lors de son appel dans une des classes filles ?

Lors de l'appel de la fonction lister (dans une des classes fille), on aurait quelque chose comme cela :

Code:

---

1 2 3

// Par exemple, si on est dans la classe fille "ArticleAcheté", // au niveau de l'appel, cela pourrait donner : Program.lister<T>() where T : ArticleAcheté new;

---

Cependant, le bout de code ci-dessus, reste fictif car dans la pratique cet appel de la fonction Lister, ne marche pas...mais l'idée est la !

pour le createinstance avec un string en paramètre, je teste de suite...:?

Merci pour l'idée !

Voila, près avoir esseyer le createinstance, ca doner quelque chose comme ca :

Code:

---

1 2 3 4 5

string nomClasse = "ArticleAcheté"; static public void liste(string nomClasse) { object toto = Activator.CreateInstance(nomClasse); }

---

--> Ce procédé ne marche pas : l'objet toto est bien créer mais il ne dispose pas des méthodes et attributs de la classe fille paramétré dans le string nomClasse("ArticleAcheté")

Il y a seulement 4 méthodes génériques, fournient par défaut par le compilateur : GetHashCode, ToString, GetType, Equals !

une fois instancié, l'intellisense ne propose que les choses en fonction de la déclaration du type, si tu veux avoir accès aux méthodes, il faut typer ta variable et pas la mettre as object
si tes classes sont hérité de quelque chose pour qu'elles aient toutes les meme methodes, il faut type selon la classe de base

et en vb on If TypeOf Machin Is Truc pour ensuite pourvoir faire d'autres choses, je crois que c'est avec gettype en c#

A la base, c'est ce que j'avais fait dans le message 11
Regarde ici :
http://www.developpez.net/forums/d63...g/#post3744778

Et dans chacun des 2 cas (avec un cast de mon type ou avec un object), cela pose les 2 même problème :
- Soit il faut clairement désigner le nom de la classe fille, si je type (cast) ma variable
- Soit mon objet est bien créer en tant que "object toto = ...", c'est à dire qu'il n'est pas typé, mais je ne n'accède pas aux methodes specifique de la classe fille !

Y aurait-il un moyen pour caster (ou typer) ma variable sans forcement désigner le nom de la classe fille ("ArticleAcheté" dans l'exemple du message 11) ?

Citation:

---

Envoyé par beetlejuice722

Ma question est: Ce fameux <T>, peut-il être paramètré en amont de le fonction Lister, c'est à dire lors de son appel dans une des classes filles ?

---

Oui. Je t'invite à consulter un tutorial sur les generics. Ici tu aurais

Code:

---

1 2 3 4 5

// dans ArticleEpuisé Program.Lister<ArticleEpuisé>(); ... // dans ArticleMachin Program.Lister<ArticleMachin>();

---

Simple, n'est-ce pas ?

Et d'ailleurs, le mot-clé where ne sert que dans la déclaration de la méthode, pas dans son utilisation.

Je sait qu'en Java, l'instruction Class.forname(string var) pourrait régler ce problème, mais je vois aucun équivalent en C# !!

Merci Guulh !

Je viens d'essyer l'appel de la fonction lister avec le :

Code:

---

1 2	// dans ArticleEpuisé Program.Lister<ArticleEpuisé>();

---

Mais que peut on mettre au niveau de la fonction Lister (dans classe program), car le "<ArticleEpuisé>", n'est pas un arguments transportable !!

Pour l'entete de la fonction Liste, j'ai esseyer ceci dans la classe program :

Code:

---

1 2 3 4 5

static public void lister<T>() { T toto = new T(); toto.getNomArticleEpuise(); // cela ne marche pas ! }

---

Mais lorsque j'utilise l'objet toto, les méthodes spécifiques de la classe fille ("ArticleEpuisé" dans ce cas), ne sont toujours pas accessible !

Citation:

---

car le "<ArticleEpuisé>", n'est pas un arguments transportable !!

---

?

Citation:

---

Envoyé par beetlejuice722

Mais lorsque j'utilise l'objet toto, les méthodes spécifiques de la classe fille ("ArticleEpuisé" dans ce cas), ne sont toujours pas accessible !

---

Je répète ce que je disais tout à l'heure : dans ta méthode Lister, tu veux utiliser une méthode qui n'existe QUE DANS ArticleEpuisé.

Donc ta méthode ne marchera pas avec un ArticleBidule, non ? Donc ta méthode ne marchera qu'avec un ArticleEpuisé, non ?

Donc ta méthode, c'est bien ListerArticleEpuisé ?

Ou bien alors tu as un truc du style (en pseudo code)

Code:

---

1 2 3 4 5

if (type == ArticleEpuisé) { toto.UneMethodeQuiNEXisteQueDansArticleEpuisé(); .... }

---

dans ton code ?

Pour résumer, il s'agit d'une méthode Lister qui se veut généraliste...

En ce sens, on doit pouvoir lister indépendamment des article épuisé OU des articles acheté ou des articles bidule...

Donc, dans le menu général (main) si je choisit de gérer des articles acheté, je pourrais dans un sous-menu (dans la classe fille ArticleAcheté), lister des articles acheté...
De même, si je choisit de gérer des articles épuisé dans le manu général, je pourrais dans un sous-menu (celui de la classe fille ArticleEpuisé), lister des articles épuisé...

Mon but est le suivant :
Que je liste des article acheté, ou que je liste des articles épuisé ou autre, je doit toujours faire appele à la même fonction Lister (Program.Lister)...
Ce qui doit changer entre chaque sous-type d'article (épuisé ou acheté,etc...)
c'est le contenu de la variable string maclasse qui est passé en paramètre lors de l'appel !

Donc si je liste des Article Acheté : dans la classe fille "ArticleAcheté", on aura
un appel de la fonction Lister, comme ceci :

Code:

---

1 2	string nomClasse = "ArticleAcheté"; Program.Lister(nomClasse);

---

De même, si je liste des Article Epuisé : dans la classe fille "ArticleEpuisé", on aura un appel de la fonction Lister, légérement différent :

Code:

---

1 2	string nomClasse = "ArticleEpuisé"; Program.Lister(nomClasse);

---

La seule difference, c'est la valeur contenue dans la variable string, laquelle indique clairement le nom de la classe à instancier par la suite !

Merci encore pour ton aide...:P

Oui mais ça sert à quoi d'appeler une seule méthode, si au final elle est sensée faire des choses complètement différentes en fonction du type d'un objet ?

En quoi ça t'embête de faire des méthodes

Code:

---

1 2 3

ListArticleTruc() ListArticleMachin() ListArticleChose()

---

quitte à ce qu'elles appellent toutes une ListArticleBase, qui contiendrait tout le code commun ? Pourquoi tiens-tu tant à tes chaînes de caractère ? :aie:

Eh bien, le but reste avant tout d'optimiser le code en terme de volume...

S'il devait y avoir 50 classes filles par la suite, cela voudrait dire alors qu'il devrait y avoir autant de méthode ListArticleTruc() pour chaque sous type d'article...

En algo objet, je pars toujours du principe qu'il faut éviter d'avoir des extraits de codes identiques, c'est le principe même du polymorphisme !

Donc si ListArticleTruc(), ListArticleMachin() et ListArticleChose() font exactement la même chose, mais agisse sur 3 sous-types différent, il semblerait intéressant de n'avoir qu'une seule fonction Lister Global, qui permette de lister indépendement chaque sous-type d'article (bidule, machine, truc...), juste en lui indiquant vers quelle classe fille elle doit se tourner...

Je dois bien admettre que j'ai horreur du code qui se répété de nombreuses fois ! ;)

Pour la chaine de caractère, je n'y suis pas specialement attachée, mais apparement c'est le seul moyen que j'ai trouvé pour indiquer le nom de la classe fille, vers laquelle la fonction lister doit se tourner...

Le but est d'accéder par un objet aux méthodes et attributs spécifique d'une classe fille, sans qu'elle soit explicitement nommée à aucun moment à l'interieur de la fonction Program.Lister

Plusieurs choses.

Je suis laaaaaaargement d'accord quand tu dis qu'il vaut mieux éviter de dupliquer du code. C'est pas pour autant qu'il faut faire une super méthode de la mort qui prend n'importe quoi en entrée et se comporte différemment en fonction du type de l'objet. Comme je te disais, tu peux regrouper le comportement commun à tout le monde dans une méthode auxiliaire, et faire une série de méthodes spécialisées.

De plus, pourquoi Lister est une méthode statique de Program ? De ce que je vois, ce pourrait être une méthode membre de Article. Et à ce moment là, à toi les joies de abstract, virtual, override and co !

Code:

---

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

//Dans Article : protected virtual void Lister() { // code commun }   //Dans ArticleTruc : protected override void Lister() { base.Lister(); // code spécifique }

---

Et après, quel que soit l'article que tu manipules, tu fais tonArticle.Lister() et zou.

'fin ce que je veux dire, c'est que le langage C# offre suffisamment d'outils syntaxiques (vive la POO ! vive les generics ! :)) permettant de représenter ces notions de dépendance, de spécialisation, de surcharge and co, sans que l'on ait besoin de bricoler tout ça dans une méthode unique. Au boulot :)

En tout cas je te remercie pour toutes l'aide que tu m'a apporté...

Je vais re-travailler mon projet avec cette nouvelle matière !

Si cela aboutit, je reviendrait pour en faire part !

:P

Voila, après plusieurs heures de test sur mon projet je n'ai toujours pas résolu mon problème, mais je suis parvenu à mieux le cerner...

Je pense que la solution qui utilise les génériques est la + appropirée dans mon cas d'utilisation...

Pourrait-tu me donner un exemple de méthode qui appel et une qui recoit un générique ?

Si dans mon appèle j'ai :

Code:

---

Program.Lister<ArticleAcheté>();

---

Comment sera l'entete de la fonction Lister?

Par exemple, j'imagine que cela "pourrait donner" quelque chose comme :

Code:

---

1 2 3 4

static public void Lister<ArticleAcheté>() { ArticleAcheté obj = new ArticleAcheté(); }

---

Cela pose problème car ca m'oblige à nommer la class <ArticleAcheté>
Mais si je fait :

Code:

---

1 2 3 4

static public void Lister<T>() { T obj = new T(); }

---

Cela ne fonctionne pas, car le <T> ne voit aucune correspondance avec le
<ArticleAcheté> passé dans l'appel de la fonction de la classe appelante :

Code:

---

Program.Lister<ArticleAcheté>();

---

Pourrait-on par le bilais des génériques passer en paramètre la classe ArticleAcheté dans l'appel de la fonction (Ex: Program.Lister<qqchose> etc...)
dans le but de ne pas avoir à nommer explicitement la classe dans l'entete de la fonction lister (ex: static public void Lister<T>) ?

Merci pour votre aide !

Citation:

---

Envoyé par beetlejuice722

Comment sera l'entete de la fonction Lister?

---

Hello,

ça, j'ai déjà répondu à ta question :) La méthode Lister en elle-même est générique, c'est à dire qu'elle fonctionne pour plusieurs types différents.
Par exemple, connais tu les conteneurs qui sont dans System.Collections.Generic ? Comme List<T> ? List est une classe générique, c'est à dire qu'au moment où tu veux l'instancier, tu dois lui spécifier un type.
Par exemple :

Code:

---

1 2 3

List<int> liste = new List<int>(); liste.Add(4); // marche parce que Add est Add<T>, et que T est int pour l'instance "liste", et que 4 est un int liste.Add("toto"); // marche pas parce que "toto" est une string et pas un int

---

Les generics permettent de rendre les classes et les méthodes paramétrables sur le type. La déclaration de ces classes et méthodes ne fait pas intervenir un type particulier : il y a juste le nom du paramètre, "T" la plupart du temps par convention.


Donc, dans le cas qui t'intéresse, tu veux faire une méthode qui marche pour plusieurs types. Disons T1, T2, T3.
Mais tu veux :
- créer une instance de T1, T2, T3
- que T1, T2, T3 héritent d'une classe de base B

C'est là qu'interviennent les contraintes. en définissant ta méthode ainsi :

Code:

---

1 2 3 4

public static void Lister<T>() where T : new(), B { ... }

---

, tu dis que ta méthode peut être appelée avec un paramètre de type T tel que T hérite de B, et T a un constructeur par défaut.

Dans ton cas, si tu définis Lister<T> where T : new, Article, tu pourras appeler Lister<ArticleTruc>, Lister<ArticleMuche>, puisque tes ArticleXXX héritent de Article et un constructeur sans paramètre.

De nombreux tutoriaux sur les generics existent sur le net, et a fortori sur dvp.com ; cherche :)

Cela dit, en lisant rapidement la discussion, une chose me saute aux yeux. L'origine du problème n'est pas technique mais c'est clairement un problème de conception. Tu es en train d'essayer de résoudre un problème que tu n'aurais pas eu avec un design correct.
Par exemple utiliser le concept d'héritage pour catégoriser les articles en fonction de leur statut est une aberration. Un article épuisé ou acheté reste un article, c'est simplement un statut qui change. Il ne doit en aucun cas exister de classe spécifique pour les articles épuisés. Un article épuisé, c'est un article avec la propriété Disponible à false, ou un Stock à 0. Un article acheté, c'est un article dont la propriété Founisseur n'est pas null.

Si tu reprends ton design et que tu fais un ensemble propre, ce genre de problème va tout simplement disparaître.

Moralité de l'histoire, si ton problème n'a pas de solution, c'est parce que t'es planté au niveau de l'analyse.