Discussion :

[cobolfingaz]

Bonjour à tous,

Je n'ai jamais travaillé avec les interfaces, et après avoir lu sur le sujet, je crois qu'elles pourraient m'être utiles dans un cas particulier.

J'ai une classe qui représente un "modèle de document". Cependant, un document peut être de deux types : un document normal, ou un document ISO.

Ma classe nommée "document" implemente une methode DrawDocument(), qui s'occupe de batir les éléments d'un document à l'écran.

J'aimerais que ma méthode DrawDocument réagisse d'une telle façon si le document est normal, et d'une autre façon si le document est ISO.

Par exemple, la méthode DrawDocument() ajoute un sceau ISO sur le document, ce qui n'est pas convenable pour un document normal.

Mon idée (et ça prouvera si je comprends bien le concept d'interfaces) est de déclarer les interfaces IDocument et IISODocument, qui sont toutes deux implementées dans la classe Document.

Mon problème est que je ne sais pas s'il est possible d'implementer la même méthode, mais différemment, dépendamment de l'interface ?

Je ne sais pas si je m'exprime bien ... je veux seulement que ma méthode DrawDocument() réagisse différemment dépendant si elle est de type IDocument ou IISODocument.

Si je ne semble pas bien piger le concept, j'aimerais bien avoir des explications parce que les exemples que j'ai lu me donnent à penser que c'est la façon de faire.

Sinon, quelle serait la façon de résoudre ce problème ?

Merci d'avance,

[GSXRider]

Si j'ai bien compris se que tu cherche c la déclaration explicite de ton interface et celà te permet de dissocier le fonctionnement de deux méthodes communes à des interfaces implémentée tel que :

Code :

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

1
2
3
4
5
 
TypeRetourMethode IDocument.MaMethode()
{
	throw new Exception("The method or operation is not implemented.");
}

[ZaaN]

J'ai ptet mal compris, mais il me semble que tu as besoin que d'une seule interface pour encapsuler les type de doc ? (si tu veux dissocier le comportement de DrawDoc en particulier)

Il y a plusieurs manière de faire ca (un exemple) :

Il faut que ton document implemente une interface de type IDoc.
Et tu créer deux type de documents CDoc et CISODoc qui sont les deux une implementation differente de IDoc.

De l'exterieur tu traite toujours un IDoc et en interne tu specialise les comportement des document.

[Guulh]

Tu devrais faire comme ça :

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
interface IDocument
{
  void DrawDocument();
  // tu peux rajouter ici des membres communs à tes deux classes, par exemple...
  string Name;
}
 
class Document : IDocument
{
  public void DrawDocument() { ... }
  public string Name = "UnDocNormal";
}
 
class DocumentIso : IDocument
{
  public void DrawDocument() { ... }
  public string Name = "UnDocIso";
}

Après, tu pourras par exemple faire quelque chose comme ça, qui fonctionnera aussi bien pour un doc que pour un doc iso :

Code :

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

1
2
3
4
5
6
 
public void AfficheNomEtDessine(IDocument doc)
{
  Messagebox.Show("Dessin du doc dont le nom est : " + doc.Name);
  doc.DrawDocument();
}

Une autre possibilité, si tes deux classes doc et dociso sont très proches, de les faire hériter toutes les deux d'une même classe qui contient le code commun :

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
abstract class DocBase
{
  public abstract void DrawDocument();
  public string Name;
}
 
class Document : DocBase
{
  public override DrawDocument() {... }
}
 
class DocumentIso : DocBase
{
  public override DrawDocument() {... }
}

[ced600]

Personnellement je n'utiliserais pas les interfaces (non pas que ce soit une mauvaise idée), je m'orienterais tout de suite vers le patron de conception état (state design pattern).

Jettes y un coup d'oeil, je pense qu'il correspond à ce que tu souhaites faire.

[GSXRider]

Oui moi aussi je penses que l'héritage est peut être plus approprié. N'hésite pas à te servir des mots clef virtual ou abstract pour définir une logique d'implémentation de tes méthodes sur tes classes hérités

[Keihilin]

Bonjour,

dans ce cas précis, utiliser des interfaces n'est pas absolument nécessaire...

J'imagine que tes deux types de documents, bien qu'ils diffèrent par leur méthode DrawDocument(), partagent un certain nombre de propriétés; pour cette raison, une classe abstraite et de l'héritage me paraît plus approprié :

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
21
22
23
24
 
public abstract class DocumentBase
{
   // --> Insert les propriétés et méthodes communes à tes deux types
   // de documents
 
   public abstract void DrawDocument() {}
 
}
 
public class Document : DocumentBase
{
   public override void DrawDocument()
   {
 
   }
}
 
public class DocumentIso : DocumentBase
{
   public override void DrawDocument()
   {
   }
}

Les interfaces sont plutôt (mais pas uniquement) utiles pour déclarer un comportement commun à une série d'objet qui n'ont pas de rapport d'héritage entre eux.

[ced600]

une classe abstraite et de l'héritage

Plus qu'à rajouter une méthode de changement d'état et tu as le patron de conception état

L'idée est simple :
Ta classe Document peut avoir plusieurs "Etats" :
- Normal.
- Iso.
- Indéterminé.
- Pas un document.
On va alors crée autant de classe qu'il y a d'états. Chacun des états hérite d'une classe abstraite qui définis toutes les méthodes que ces états doivent implémenté.
Cela apporte son incovénient, si 1 de tes classes états possède une méthode particulière, comme elle est définis dans la classe abstraite, toutes les classes doivent la contenir (l'implémentation peut être vide).

Ensuite reste plus qu'a faier une classe controleur.
Cette classe instancie toutes les classes états, une variable état courant qui contient l'instance de l'état courant, et une méthode change état qui change l'état courant.
Elle contient aussi toutes les méthodes de la classe abstraite. Ces méthodes ne ferons qu'un simple appel des méthodes correspondantes d'état courant, et avant ou après l'appel tu pourras (ou non) gérer le changement détat grace à changeEtat.

[Keihilin]

Plus qu'à rajouter une méthode de changement d'état et tu as le patron de conception état

C'est pas moi qui t'ai fait découvrir ce pattern ?

L'idée est simple :
Ta classe Document peut avoir plusieurs "Etats" :
- Normal.
- Iso.
- Indéterminé.
- Pas un document.

Alors là, à mon grand regret, je ne suis absolument pas d'accord. J'ai beau faire un effort, j'ai le plus grand mal à considérer un "type" comme un "état", surtout avec l'ajout de l'état "Pas un document"...sur un objet Document

Je vois où tu veux en venir, mais il ne faut pas oublier la définition première du "State Design Pattern" : "Alter an object's behavior when its state changes".
Cela implique un objet qui peut potentiellement changer d'état pendant son cycle de vie, or il ne me semble pas que ce comportement s'applique à un Document.

[ced600]

C'est pas moi qui t'ai fait découvrir ce pattern ?

Désolé de te décevoir mais cela m'éttonerais.
je l'ai appris en formation il y a pratiquement trois ans, donc 1 an avant mon inscription sur ce forum
Peut être m'as tu aidé à trouver l'implémentation de ce design pattern en C#, perso je ne me souviens plus si je l'ai trouvé tout seul ou si j'ai demandé de l'aide sur ce forum.

Alors là, à mon grand regret, je ne suis absolument pas d'accord. J'ai beau faire un effort, j'ai le plus grand mal à considérer un "type" comme un "état", surtout avec l'ajout de l'état "Pas un document"...sur un objet Document

Je sais mais c t plus rigolos

Je vois où tu veux en venir, mais il ne faut pas oublier la définition première du "State Design Pattern" : "Alter an object's behavior when its state changes".
Cela implique un objet qui peut potentiellement changer d'état pendant son cycle de vie, or il ne me semble pas que ce comportement s'applique à un Document.

Tout à fait raison, je l'avais oublié justement. Etant un des premiers pattern que j'ai appris (avant même le singleton), je le vois partout en conception (pareil pour le dispatcher). Je sais c pas bien, faut l'utiliser que lorsqu'il est parfaitement adapté

[Chubyone]

Par contre là je verrais bien une factory simple pour instancier le bon document.

On ne connait rien à part "Document", on passe en paramètre le type de document que l'on souhaite et il créer le bon document nécessaire.


Cela dit je créerais quand même un IDocument avec une interface "parfaitement" définie. La classe abstraite Document est une factory pour créer le document spécifique (ISO ou Normal ou tout ce que tu veux d'autre)

Ce qui fait qu'au final, tu ne manipules que IDocument et tu te cognes bien de savoir s'il est iso ou pas...

[Keihilin]

Par contre là je verrais bien une factory simple pour instancier le bon document.

forcément.

Cela dit je créerais quand même un IDocument avec une interface "parfaitement" définie.

Bof bof...Non pas que c'est mauvais hein, mais en l'état actuel des explications de cobolfingaz je n'en vois pas l'utilité.

[Chubyone]

C'était juste un "ou cas ou" il souhaite un jour redéfinir sa classe document

Pour le "forcément" : pour toi oui, pas pour lui

Il aurait pu faire

Code :

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

 Document document = new DocumentISO();

un peu partout

[SaumonAgile]

Mon avis sur la question.

Interface IDocument : les deux types de documents ont beaucoup trop de comportements communs pour qu'une interface soit suffisante. Dans ce cas, être un document n'est pas un comportement commun, mais nous sommes plutot en présence de plusieurs documents dont seuls certains aspects diffèrent.

DocumentBase comme classe de base : +1

Design Pattern Etat : Surconception (over-engineering) à mon avis.

[ced600]

Interface IDocument : les deux types de documents ont beaucoup trop de comportements communs pour qu'une interface soit suffisante. Dans ce cas, être un document n'est pas un comportement commun, mais nous sommes plutot en présence de plusieurs documents dont seuls certains aspects diffèrent.

Cela viens de me faire penser à une chose, il existe pas un pattern spécialisation ?
Peut être cela conviendrais à la demande.

Bon j'ai pas trouvé mais l'objet composite pourrait faire l'affaire ?

[cobolfingaz]

Merci de vos réponses. Je serais plus tenté de créer une classe abstraite et créer deux classes qui en héritent et modifier l'implementation de la méthode qui les fait agir différemment.

Malheureusement, je connais rien aux design patterns ... peut-être pourriez-vous me suggérer de la bonne documentation sur le sujet ?

En attendant, je vais créer une classe abstraite et mes deux autres classes.

Une dernière petite question :

J'ai l'habitude de créer un fichier .cs par classe. Devrais-je donc créer un fichier .cs pour la classe abstraite, un autre .cs pour ma classe Document et un autre .cs pour la classe IsoDocument ? Ou est-ce mieux de toutes les déclarer dans le même fichier .cs ?

Merci encore !

[Keihilin]

Une dernière petite question :

J'ai l'habitude de créer un fichier .cs par classe.

C'est très bien, continue comme ça...

Une classe --> un fichier
Une interface --> un fichier
Un enum --> un fichier

[ZaaN]

Merci de vos réponses. Je serais plus tenté de créer une classe abstraite et créer deux classes qui en héritent et modifier l'implementation de la méthode qui les fait agir différemment.

oui c'est une bonne solution

Malheureusement, je connais rien aux design patterns ... peut-être pourriez-vous me suggérer de la bonne documentation sur le sujet ?

Je te conseille l'ouvrage suivant Design Pattern Head First.

Et ptit rappel à TOUS : utiliser des patterns uniquement là ou le besoin s'en fait sentir.

Une dernière petite question :

Devrais-je donc créer un fichier .cs pour la classe abstraite, un autre .cs pour ma classe Document et un autre .cs pour la classe IsoDocument ? Ou est-ce mieux de toutes les déclarer dans le même fichier .cs ?

personnelement je met une seule classe par .cs. Sauf pour les classes imbriquées.
Mais rien ne t'y oblige à part ton ben sens eventuellement.

[SaumonAgile]

Une classe - un fichier... Un peu simpliste, à mon avis.
Je dirais plutôt "pas plus d'une classe par fichier". Il est parfois nécessaire d'utiliser plusieurs fichiers par classe.

[Keihilin]

Il est parfois nécessaire d'utiliser plusieurs fichiers par classe.

Arf ! Encore un qui a cédé à la tentation des classes partielles !!! VADE RETRO