Discussion :

[beetlejuice722]

Merci Guulh !

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

Code :

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

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 :

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

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 !

[Guulh]

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

?

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 :

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

1
2
3
4
5
if (type == ArticleEpuisé)
{
   toto.UneMethodeQuiNEXisteQueDansArticleEpuisé();
 ....
}

dans ton code ?

[beetlejuice722]

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 :

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

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 :

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

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...

[Guulh]

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 :

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

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 ?

[beetlejuice722]

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 !

[beetlejuice722]

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

[Guulh]

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 :

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

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

[beetlejuice722]

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 !

[beetlejuice722]

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 :

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

Program.Lister<ArticleAcheté>();

Comment sera l'entete de la fonction Lister?

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

Code :

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

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 :

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

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 :

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

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 !

[Guulh]

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 :

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

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 :

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

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

[SaumonAgile]

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.