Discussion :

[dev01]

Bonjour à tous.

J'ai un petit problème de conception.
Voici la situation : J'hérite d'un contrôle ( on va dire Grid ) et je veux lui rajouter des fonctionnalités. Jusque la rien de méchant, l'héritage c'est fait pour ça. Le problème c'est que les fonctionnalités à rajouter à ce contrôle doivent être également rajouté à d'autre contrôle ( exemple : StackPanel ). Etant donné que je ne maitrise pas la hiérarchie d'héritage ( ce sont des controles "System.Windows.Controls" ) je ne peux pas avoir de classe commune. De plus le choix de l'interface ne passe pas non plus car j'ai besoin d'un certain nombre d'élément static. ( les interfaces n'acceptent pas les éléments static ).

Le pattern decorator ne peux pas être appliqué car je ne maitrise pas l'héritage.

Bref je suis bien embetté car je ne voit aucun moyen de factoriser le code d'héritage qui est pourtant commun à toutes les classes que je vais créer

[davcha]

DP Composition, avec tes membres statiques sur l'implémentation de la composition ?

[olsimare]

Bonjour.

Je suis peut être complétement à côté mais ne peux-tu mutualiser le code commun via un classe static ? Un truc comme ce que TomLev avait proposé ici :
http://www.developpez.net/forums/sho...d.php?t=524342

Cdt.

[Thomas Lebrun]

J'hérite d'un contrôle ( on va dire Grid ) et je veux lui rajouter des fonctionnalités.

Hum.. par fonctionnalités, tu veux dire propriétés, méthodes ou propriétés et méthodes ? Car, si j'ai bien lu ton message, tu fais du WPF or pour ce genre de cas, si tu veux "juste" rajouter des prop, tu peux passer par des propriétés attachées.

[dev01]

Hum.. par fonctionnalités, tu veux dire propriétés, méthodes ou propriétés et méthodes ? Car, si j'ai bien lu ton message, tu fais du WPF or pour ce genre de cas, si tu veux "juste" rajouter des prop, tu peux passer par des propriétés attachées.

Justement le but est de fournir des propriétés attachés pour les contrôles enfants.

En gros je rajoute : Une dépendencyProperty, deux méthode static ( Get et Set ).

[SaumonAgile]

Tu as pensé à PostSharp pour injecter les nouveaux comportements dans les contrôles ?

[dev01]

Tu as pensé à PostSharp pour injecter les nouveaux comportements dans les contrôles ?

Mouais pas bete ... je vais y réflechir.

Mais le problème de conception est toujours la. Il y a rien pour faire ce genre de chose ?

[dev01]

Je viens de vérifier et malheureusement PostSharp ne peux pas répondre à cette problématique.

D'autres propositions ?

[_skip]

Et le pattern Strategy ?
C'est à dire déclarer les méthodes communes dans une classe externe puis utiliser une référence de cette classe dans tes fameux controls?

Tu définis une classe de pseudo-interface comme ceci :

Code :

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

1
2
3
4
5
6
abstract class MyControlStrategy
{
    public static XXX = 10;
    public void DoSomething1() ....
    public void DoSomething2() ....
}

Tu implémentes les spécificités de tes contrôles dans des classes concrètes :

Code :

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

1
2
3
4
public class MyStackPanelStrategy : MyControlStrategy
{
     public override void DoSomething2() {do something specific}
}

Ensuite de façon transparente dans tes contrôles, tu instancies la stratégie au niveau du constructeur :

Code :

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

1
2
3
4
5
6
public class MyStackPanel
{
     private MyControlStrategy _strat;
 
     public MyStackPanel() { _strat = new MyStackPanelStrategy(); }
}

Si les méthodes DoSomethingxxx() sont destinées à être appelées depuis l'extérieur de la classe, tu publies _strat en public avec une propriété Get;

Par ailleurs, tu peux créer une interface que tu fais implémenter à tous tes contrôles spéciaux qui permet de récupérer la stratégie :

Code :

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

1
2
3
4
5
 
public interface IMySpecialControls
{
      MyControlStrategy Strat get;
}

Ca fournit à la fois la réutilisabilité et l'abstraction. Futée l'araignée

[dev01]

gneuhhhh

Je vais réfléchir, prendre un ou deux aspirines et de te dire si ça marche ou pas.

[bilb0t]

Moi ce que je ferai (et je ne sais pas si ça correspond à un design patern) c'est ceci:

imaginons 2 fonctionnalités semblables pour 2 classes qui sont des contrôle (ex: grid et DropDown)

1. Je crée mes classes:

Code :

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

1
2
Class MaClasseGrid : Grid
Class MaClasseDD: DropDown

2. Je crée un interface qui va me fournir mes fonctionnalités:

Code :

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

1
2
3
4
5
6
Interface INewFct
{
  Method1
  MethodN
  Propr1
}

3. Je crée une classe éventuellement abstraite qui implémente l'interface. Celle ci va définir le fct commun.

Code :

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

1
2
3
4
5
6
(abstract) NewFct : INewFct
{
  abstract/virtual Method1{...}
  abstract/virtual MethodN{...}
  abstract/virtual Propr1{...}
}

4. Je crée un interface qui me permet d'accéder à mes nouvelles fct.

Code :

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

1
2
3
4
Interface INewFctProvider
{
  INewFct NewFct{get;}
}

5. Mes classes contrôle implémente INewFctProvider. Celle ci retourbe alors soit la classe de base, soit une classe dérivée ci besoin. J'évite ainsi le code copié collé dans toutes les classes qui implémentent l'interface.

Code :

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

1
2
3
4
5
6
7
8
Class MaClasseGrid : Grid, INewFctProvider
{
  INewFct{get{return new NewFct();}}
}
Class MaClasseDD: DropDow, INewFctProvider
{
 INewFct{get{return NewDerivedFct();}}
}

voilà, je ne sais pas si c'est clair, mais ça me permet d'avoir une sorte d'héritage multiple.

[davcha]

C'est pas une version étrange du DP Composition, ça, par hasard ?...

[bilb0t]

C'est pas une version étrange du DP Composition, ça, par hasard ?...

(et je ne sais pas si ça correspond à un design patern)

Plus sérieusement, je ne connais pas le design pattern composition.

Mais si tu entends par là l'object composition, je ne suis pas d'accord. Mon système permet d'avoir des instances dérivée et non "d'englober" un "master classe" dans une "sous-classe".

[davcha]

Code c# :

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
25
26
27
28
interface ITrucable
{
  void TrucMe();
}
 
class TrucImplementation
{
  object _instance;
 
  public TrucImplementation(object instance){
    _instance = instance;
  }
 
  public void TrucMe(){...}
}
 
class Bidule : ITrucable
{
  ITrucable truc;
 
  public Bidule(){
    truc = new TrucImplementation(this);
  }
 
  public void TrucMe(){
    truc.TrucMe();
  }
}

[bilb0t]

Hello,

Merci pour ta définition.

En fait c'est exactement sauf que...

Ce que je cherche à éviter c'est le copier coller de code. Avec ton DP si dessus, si ton interface propose 10 méthodes, et si tu as 15 classes qui l'implémente, tu vas te retrouver avec le code d'appel des 10 méthodes dans tes 15 classes...

Mon truc c'est le petit plus en plus. Je n'ai que l'appel qui est copié collé.

[davcha]

En effet, d'où l'implémentation "étrange" du DP composite.

Ceci dit, en utilisant PostSharp, on peut éviter de se taper les 15 lignes dont tu parles.

[bilb0t]

Oui, mais...

Je suis pas un grand fan de l'AOP... Perso, ça me heurte par rapport à ma conception de l'OO.

Et puis bonjour le debug avec les tisseurs d'aspect !

[davcha]

Le debuggage de PostSharp est encore assez bien intégré, je trouve.

Le seul reproche que j'ai à lui faire, en fait, c'est qu'il alourdit un peu les traitements quand même...

Tu peux toujours voir du côté de l'implémentation automatique d'interfaces aussi, avec les AssemblyBuilder, mais ça revient à programmer une partie de ton truc en msil, directement. Et là, effectivement, c'est pas évident pour le debuggage.

[dev01]

J'ai pas eu le tempsd e faire des tests mais il y a un truc qui me gene avec vos proposition : elles sont toutes basées sur des interfaces et les interfaces ne supportes pas les méthodes statiques. Or tout mon pb vient de ces fameuses méthodes statiques ...

[Keihilin]

Est-ce que tu peux détailler un peu plus ce que tu veux ? Parce que j'ai lu ton premier message et le reste un peu en diagonale, mais à mon sens il y a déjà une petite contradiction entre les termes "héritage multiple" et "static"...du coup j'ai de la peine à cerner le problème.