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() {... }
}

[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]

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.