[Archi. Logicielle] Design Pattern Strategy - Incrustation dans un projet

Hello,

Pas de question spécialement sur le pattern en lui-même, simplement une question pour avoir votre avis sur le positionnement des classes dans l'architecture logicielle. (Et cela permettra également à ceux qui ne connaissent pas ce pattern de l'aborder)

Ce design pattern strategy sera utilisé par un WebService pour déterminer sa stratégie de "data mining" (c'est un bien grand mot, mais bon...).
Pour faire simple, disons que c'est la donnée qui détermine la stratégie (si c'est le produit X, alors le pré-traitement sera ça, le post traitement ça), avec un traitement commun à tous les produits.
Je précise que c'est une évolution d'un existant, où il n'y avait à l'époque qu'une seule stratégie (et donc pas de pattern en place), et que le WebService s'incorpore dans un ensemble plus grand, il utilise donc des couches métiers communes à d'autres applications.

Grossièrement, voici l'algorithme :
> Réception d'une requête XML
> Analyse de la requête
> Recherche du type de la donnée (accès à la base)
> Choix de la stratégie
> Pré-traitement, si nécessité par la stratégie (accès à la base ou non)
> Traitement commun (accès à la base)
> Post-traitement, si nécessité par la stratégie (accès à la base ou non)
> Incorporation des données dans un XML
> Envoi de la réponse XML

Pattern Strategy en lui-même, je pense faire une arborescence de ce type là :

- une classe DataMining qui définie le traitement commun
- une interface DataMiningStrategy
- deux classes ConcreteStrategyProductX et ConcreteStrategyProductY, qui définiront leurs pré et post traitement, et qui héritent de DataMining pour utiliser le même traitement commun
- une classe Context avec une référence vers DataMiningStrategy, et qui exécutera selon le produit, l'une ou l'autre des ConcreteStrategy

De plus, une contrainte projet impose l'utilisation d'une architecture logicielle propre à ma boite, qui organise la solution en briques techniques (proxy, modèles génériques d'exception, de logs, mapping à la base, etc...), briques "métier" (comme des Beans en Java) qui définissent chacune des aspects métiers (potentiellement sur les mêmes entités qu'une autre brique métier) et en briques applicatives, qui s'appuyent sur les briques techniques et métier.

Donc, ma question dans tout ça...

Etant donné que certaines des classes du Design Pattern Strategy utilisent des couches métiers, mais qu'elles définissent la stratégie propre au WebService, dans quelle brique logicielle doivent-elles être définies ?

- Dans le WebService
ou
- Dans une brique technique, sur lequel le WebService a une référence
ou
- Dans une brique métier, sur lequel le WebService a une référence

Habituellement, je pense que c'est fait au sein de l'application, donc ici du WebService, sauf que pour moi ça viole le découpage qui a été fait au niveau logiciel, dans le sens ou le Design Pattern contient une implémentation métier.

Je penche donc plutôt sur la troisième hypothèse, même si j'emets une réserve du fait qu'elle ne sera utilisée que par une seule brique applicative, et du fait que ça ne soit pas vraiment une brique métier, dans le sens où elle est modelée par le Design Pattern, et ne suit plus la découpe de la guideline originelle...


Si ça manque de détail n'hésitez pas ! ;)

Merci d'avance !

PS : Quand le code sera fait je posterai l'implémentation du Design Pattern Strategy pour ceux que ça intéresse. Je ne sais pas s'il existe pas déjà un tuto sur DVP en C# là dessus...

Voici le début de l'implémentation :

La classe mère :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

public class DataMiningProcess { public virtual void PreProcess() { // jamais appelée, sinon c'est un problème... throw new NotImplementedException("DataMiningProcess.PreProcess"); }   public virtual IList<Item> Process(String param1, String param2) { this.PreProcess(); IList<Item> itemsList = new List<Item>(); this.PostProcess(); return itemsList; }   public virtual void PostProcess() { // jamais appelée sinon c'est un problème... throw new NotImplementedException("DataMiningProcess.PostProcess"); } }

---

L'interface :

Code:

---

1 2 3 4 5 6 7

public interface DataMiningStrategy { void PreProcess(); IList<Item> Process(String param1, String param2); void PostProcess(); }

---

Une des classes filles :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class ConcreteDataMiningStrategyProductX : DataMiningProcess, DataMiningStrategy { #region DataMiningStrategy Members   public override void PreProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PreProcess - This methode does nothing but who cares ?"); }   public override IList<Item> Process(String param1, String param2) { return base.Process(param1, param2); }   public override void PostProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PostProcess - This methode does nothing but who cares ?"); }   #endregion }

---

La classe consommatrice dans le WebService :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// [...] String Denomination = ProductManager.GetProductDenomination(someKey); DataMiningContext context; // Choose strategy according to product denomination switch (Denomination) { case "ProductX" : context = new DataMiningContext(new ConcreteDataMiningStrategyProductX()); break; case "ProductY" : context = new DataMiningContext(new ConcreteDataMiningStrategyProductY()); break; default: throw new Exception("Product denomination is not valid"); } // Execute the appropriate strategy itemList = context.ExecuteStrategy(param1, param2); // [...]

---

Pour info, Item est un objet métier défini par ailleurs.

EDIT : Réflexion faite, je pense que les appels vers PreProcess et PostProcess seront faits directement depuis la méthode Process.

Le code semble bien marcher, et j'ai choisi l'option 3.

Des commentaires/remarques/améliorations ?

si j'ai bien suivi, je pense que la classe de base appelle les pre et post process et en effet la meilleure solution, ca ne mélange rien
et vu que tu fais pré process>process>postprocess, l'encapsulation dans process est tout à fait logique si la classe process a ce qu'il faut pour déterminer les pré et post process à appliquer

Bonjour,

C'est-à-dire : Dans une brique métier, sur lequel le WebService a une référence

Je n'avais pas vu ton post avant, mais de mon point de vue heureusement que tu as choisi de mettre ça là car c'est purement métier !

Je ne connaissais pas ce pattern avant de lire ton post mais je trouve que l'implémentation qui en est faite est assez légère à mon goût !

Si je prends l'exemple de wikipedia, voici ce qui me gêne :

Code:

---

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

// une liaison tardive switch (météo) { case Météo.IlFaitBeau: kevin.Strategie = new DéfoncerLePontLevisDeFace(); break; case Météo.IlYADuBrouillard: kevin.Strategie = new PasserParLaFaceNord(); break; case Météo.IlFaitTropChaudPourTravailler: kevin.Strategie = new AttendreQueLaVilleSeRende(); break; case Météo.IlPleut: kevin.Strategie = new SeMarierAvecLaCousineDuDuc(); break; default: throw new Exception("Nan finalement seigneur de la guerre c'est " + "pas cool comme job : vous décidez d'aller élever " + "des chêvres dans le Perigord."); }

---

Je trouve ça peu élégant et fait perdre un peu de l'intérêt au pattern. Je partirai sur l'idée d'une Factory (remplissant le rôle du new ...()) conditionnelle (remplissant le rôle du switch).

Cela permettrait notamment de complexifier les conditions de manière transparente par rapport à l'appel et d'ajouter aisément de nouvelles stratégies (faisable si on pousse le bouchon un peu loin) via de la configuration (mais je pars très loin là quand même)...

J'ai surement loupé un truc, mais pourquoi ta classe de base n'implémente pas directement l'interface. Et puis pourquoi une virtual qui Throw plutôt qu'une abstract ?

Citation:

---

Envoyé par ostenhard

Je trouve ça peu élégant et fait perdre un peu de l'intérêt au pattern. Je partirai sur l'idée d'une Factory (remplissant le rôle du new ...()) conditionnelle (remplissant le rôle du switch).

Cela permettrait notamment de complexifier les conditions de manière transparente par rapport à l'appel et d'ajouter aisément de nouvelles stratégies (faisable si on pousse le bouchon un peu loin) via de la configuration (mais je pars très loin là quand même)...

---

Merci pour ton input. Je prends note mais je ne sais pas si je vais avoir le temps d'implémenter "en plus" le pattern factory. Mais c'est vrai qu'ils vont bien ensemble !

Citation:

---

Envoyé par nevaram

J'ai surement loupé un truc, mais pourquoi ta classe de base n'implémente pas directement l'interface. Et puis pourquoi une virtual qui Throw plutôt qu'une abstract ?

---

Parce que la classe mère, DataMiningProcess, n'est pas une stratégie.
EDIT : Pour l'abstract je réponds plus bas

Citation:

---

mais pourquoi ta classe de base n'implémente pas directement l'interface

---

Car si la classe de base implémente directement l'interface, elle ne pourra avoir qu'une seule implémentation donc qu'une seule stratégie.

Pour faire une image, je dirais que la classe de base tel qu'implémenter ici, son boulot c'est de savoir quelle stratégie elle a à sa disposition et laquelle utiliser dans quel cas mais par contre elle ne veut rien savoir de comment se déroule la stratégie.

En gros, elle sait que toutes les stratégie vont l'amener au résultat souhaité mais elle s'en fout de comment on va s'y prendre.

EDIT : ah ben je m'enflamme !

Exact.
Et pour l'abstract, c'est parce que ça m'oblige à avoir la classe abstract elle aussi, ce qui n'es pas souhaité car la méthode Process est appelée depuis les classes filles.

Ok, je n'ai pas regarder le problème dans son ensemble. Je me suis arrêté au fait que DataMiningProcess avait les mêmes méthodes que IDataMiningStrategy. :aie:

Citation:

---

Car si la classe de base implémente directement l'interface, elle ne pourra avoir qu'une seule implémentation donc qu'une seule stratégie.

---

En fait je pensé faire implémenter IDataMiningStrategy mais en laissant les méthodes PreProcess et PostProcess abstract, ce qui aurait fait que c'est bien les classes filles qui aurait vraiment implémentée l'interface.

Code:

---

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

public abstract class DataMiningProcess : IDataMiningStrategy { public abstract void PreProcess();   public virtual IList<Item> Process(String param1, String param2) { this.PreProcess(); IList<Item> itemsList = new List<Item>(); this.PostProcess(); return itemsList; }   public abstract void PostProcess(); }

---

Bonjour,

Ton implémentation du pattern Strategy me choque un peu Oo
Je suis plutôt de l'avis de nevaram sur le fait qu'il serait préférable que
Ta classe DataMiningProcess implémente IDataMiningStrategy,
Juste pour avoir la sureté d'avoir les bons appels
(si tu changes ton interface, la classe devrait changer aussi)
De plus, ça semble bizarre qu'une classe fille doivent hériter des deux ...

Sache aussi que tu n'a pas un pattern Strategy simple,
Tu as aussi un pattern Template Method (la méthode Process),
Donc je ne vois pas pourquoi cette méthode se retrouve dans l'interface ?
A moins que tu veuilles laisser la possibilité de changer complètement cette méthode Oo

Je verrai plus une implémentation comme :

Code:

---

1 2 3 4 5 6

public interface IDataMiningStrategy { void PreProcess(); void PostProcess(); }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

public class DataMiningProcess : IDataMiningStrategy { private IDataMiningStrategy strategy;   public void PreProcess() { strategy.PreProcess(); }   public virtual IList<Item> Process(String param1, String param2) { this.PreProcess(); IList<Item> itemsList = new List<Item>(); this.PostProcess(); return itemsList; }   public void PostProcess() { strategy.PostProcess(); } }

---

Code:

---

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

public class ConcreteDataMiningStrategyProductX : IDataMiningStrategy { #region IDataMiningStrategy Members public override void PreProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PreProcess"); }   public override void PostProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PostProcess"); } #endregion }

---

Je suis d'accord pour dire qu'on n'est pas d'accord ! :)

Pour moi, DataMiningProcess n'est pas une stratégie, et donc n'a pas à implémenter l'interface DataMiningStrategy. J'ai ici défini une stratégie pour le Data Mining pour des produits, mais je pourrais très bien le faire pour complétement autre chose, qui ne nécessiterait par exemple pas de pré-traitement, mais nécessitera à la place un sérialisation dans un fichier XML.

DataMiningProcess n'a d'ailleurs pas nécessairement vocation à définir UNIQUEMENT l'aspect stratégie, et pourrait très bien permettent de définir d'autres méthodes "DataMining" indépendantes des stratégies.

(D'ailleurs, les classes filles n'héritent pas de DataMiningStrategy, elles l'implémentent, qu'on soit d'accord au moins sur le terme :p)

Pour ce qui est de la méthode Process, là en revanche je te rejoins, et je me suis posé la question de savoir s'il fallait ou non la mettre dans l'interface. J'ai fini par considérer que oui, pour assurer une cohésion : c'est dans la méthode Process que se font les appels vers PreProcess et PostProcess, et c'est bien cette méthode Process qui renvoit la liste d'éléments.

Par contre je ne comprends pas ton implémentation : tu implémentes DataMiningStrategy et en plus tu fais un agrégat dessus ?

Citation:

---

Envoyé par Er3van

Pour moi, DataMiningProcess n'est pas une stratégie, et donc n'a pas à implémenter l'interface DataMiningStrategy.

---

Oui j'ai bien compris ça ^^
J'ai juste dit par soucis de cohérence, il est très fréquent qu'on le fasse.
Ça évite par exemple d'avoir deux méthodes ayant la quasi même signature.

Citation:

---

Envoyé par Er3van

J'ai ici défini une stratégie pour le Data Mining pour des produits, mais je pourrais très bien le faire pour complétement autre chose, qui ne nécessiterait par exemple pas de pré-traitement, mais nécessitera à la place un sérialisation dans un fichier XML.

---

Si le besoin de sérialiser au lieu de faire un pré-traitement ne change pas le reste de la méthode Process,
Il me semble logique que la phase de sérialisation soit une sorte de pré-traitement et devrait donc être codée en conséquence.
Le pattern Template Method ne suppose pas que tu es qu'un type d'élément,
Mais que tu es plusieurs éléments qui ne diffèrent que sur certains points d'un (ou plusieurs) algorithme(s).

Citation:

---

Envoyé par Er3van

DataMiningProcess n'a d'ailleurs pas nécessairement vocation à définir UNIQUEMENT l'aspect stratégie, et pourrait très bien permettent de définir d'autres méthodes "DataMining" indépendantes des stratégies.

---

Elle le peut toujours Oo
Libre à elle de gérer comme elle le veut ses méthodes ^^
J'ai eut un exercice avec des canards qui devaient savoir ou non voler, cancaner, nager, ...

Citation:

---

Envoyé par Er3van

(D'ailleurs, les classes filles n'héritent pas de DataMiningStrategy, elles l'implémentent, qu'on soit d'accord au moins sur le terme :p)

---

Oui j'ai voulu simplifier car lorsqu'on regarde la signature de ta classe,
Elle hérite de DataMiningProcess et implémente DataMiningStrategy

Code:

---

1 2 3

public class ConcreteDataMiningStrategyProductX : DataMiningProcess, DataMiningStrategy

---

Citation:

---

Envoyé par Er3van

Pour ce qui est de la méthode Process, là en revanche je te rejoins, et je me suis posé la question de savoir s'il fallait ou non la mettre dans l'interface. J'ai fini par considérer que oui, pour assurer une cohésion : c'est dans la méthode Process que se font les appels vers PreProcess et PostProcess, et c'est bien cette méthode Process qui renvoit la liste d'éléments.

---

Je ne vois pas en quoi ça garde une cohésion en soit ...
Enfin, de la façon dont tu le fait en fait ...
Parce que, l'utilisateur ne sait pas s'il utilise un DataMiningProcess ou un DataMiningStrategy ...

Citation:

---

Envoyé par Er3van

Par contre je ne comprends pas ton implémentation : tu implémentes DataMiningStrategy et en plus tu fais un agrégat dessus ?

---

C'est ce dont je parlais justement sur garder la cohérence des classes.
Le pattern Strategy a (au moins) deux implémentations.

Soit la classe qui comporte le contexte (stratégie) l'utilise dans de façon différentes

Code:

---

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

class Context {   private Strategy strategy;   // Constructor public Context(Strategy strategy) { this.strategy = strategy; }   public int executeStrategy(int a, int b) { return strategy.execute(a, b); } }

---

[cf Wikipédia]

Soit il ressemble à un pattern Deleguate,

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public interface I { void F(); void G(); }   public class C : I { // delegation I i = new A();   public void F() { i.F(); } public void G() { i.G(); }   // normal attributes public void ToA() { i = new A(); } public void ToB() { i = new B(); } }

---

[cf Wikipédia]

Citation:

---

Envoyé par brachior

Si le besoin de sérialiser au lieu de faire un pré-traitement ne change pas le reste de la méthode Process,
Il me semble logique que la phase de sérialisation soit une sorte de pré-traitement et devrait donc être codée en conséquence.

---

Potentiellement non, il se peut que cette sérialisation soit implémentée au niveau de DataMiningProcess, et qu'on n'impose pas aux classes filles de la redéfinir, contrairement au PreProcess.

Citation:

---

Envoyé par brachior

Elle le peut toujours Oo
Libre à elle de gérer comme elle le veut ses méthodes ^^
J'ai eut un exercice avec des canards qui devaient savoir ou non voler, cancaner, nager, ...

---

Oui, on pourrait, mais dans ce cas ça devient confus : on ne sait plus si la classe mère est-elle là pour définir une implémentation de DataMiningStrategy ou pour fournir des méthodes de DataMining, alors que c'est la deuxième option que je souhaite.

Citation:

---

Envoyé par brachior

Je ne vois pas en quoi ça garde une cohésion en soit ...
Enfin, de la façon dont tu le fait en fait ...
Parce que, l'utilisateur ne sait pas s'il utilise un DataMiningProcess ou un DataMiningStrategy ...

---

La classe utilisatrice n'a connaissance que des ConcreteStrategy, via le DataMiningContext, donc dans tous les cas elle ignore aussi bien la classe DataMiningProcess que l'interface DataMiningStrategy.

Si tu l'entends du point de vue de la classe fille, je ne vois pas en quoi c'est gênant non plus : la classe fille sait qu'elle doit implémenter trois méthodes, libre à elle d'utiliser ou non l'implémentation de Process de la classe mère, mais en tout cas elle doit redéfinir PreProcess et PostProcess.

Citation:

---

Envoyé par brachior

C'est ce dont je parlais justement sur garder la cohérence des classes.
Le pattern Strategy a (au moins) deux implémentations.

Soit la classe qui comporte le contexte (stratégie) l'utilise dans de façon différentes
[...]
Soit il ressemble à un pattern Deleguate,

---

Ok, c'est peut-être pour ça qu'on diverge, on ne l'utilise peut-être pas tout à fait dans la même optique...

Hum, je viens de voir la classe DataMiningContext (elle n'est pas détaillée ^^)
C'est elle qui joue le rôle du pattern Strategy si j'ai bien compris.

J'ai donc du mal à saisir le but de DataMinigProcess ...
Si c'est pour fournir un semblant d'implémentation lié à DataMinigStrategy,
Je ne vois pas pourquoi elle n'implémente pas l'interface.

Et si une fille peut ou non utiliser une implémentation externe
(celle de DataMiningProcess par exemple)
Elle doit soit en hériter tout simplement,
Soit l'utiliser en temps que Deleguate.
Reste que le fait qu'elle hérite/implémente deux objets
Qui ont des méthodes communes me semble peut judicieux
Pour la compréhension, la cohésion et l'évolution du code.

Si par exemple, tu modifies une signature,
Tu peux te retrouver avec deux méthodes différentes,
Et dans le meilleur des cas, avoir une erreur de compilation ...

(Je ne dis pas que ma vision est la bonne ^^ Je dis juste que moi ça me perturbe ^^)

En fait, si j'ai bien compris, tu voudrais utiliser le DataMiningProcess un peu comme un helper et dans ce cas, ce n'est effectivement pas une stratégie et donc il n’implémente pas IDataMiningStrategy.

Du coup, est-ce que ça correspond à ton besoin ?


il te faut l'interface qui définit une stratégie

Code:

---

1 2 3 4 5 6 7

public interface IDataMiningStrategy { void PreProcess(); void Process(); void PostProcess(); }

---

Un "helper"

Code:

---

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

public static class DataMiningProcess {   public static IList<Item> Process(String param1, String param2) { this.PreProcess(); IList<Item> itemsList = new List<Item>(); this.PostProcess(); return itemsList; }   }

---

et tes stratégies

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class ConcreteDataMiningStrategyProductX : IDataMiningStrategy { #region DataMiningStrategy Members   public override void PreProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PreProcess - This methode does nothing but who cares ?"); }   public override IList<Item> Process(String param1, String param2) { return DataMiningProcess.Process(param1, param2); }   public override void PostProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PostProcess - This methode does nothing but who cares ?"); }   #endregion }

---

Tu es proche (en terme de logique) de ce que je veux faire.
Sauf que dans ton cas, ça ne doit pas marcher.

Ton helper, qui est une classe statique, ne doit pas connaitre :
this.PreProcess(), ni this.PostProcess().

D'où la nécessité de les définir aussi au niveau du helper, bien que du fait de l'implémentation, ces méthodes ne soit jamais réellement appelée : c'est pour ça que dans mon implémentation elles lancent une exception.

Brachior, mea culpa, j'ai effectivement omis le DataMiningContext dans l’implémentation.

En gros, elle contient un aggrégat vers DataMiningStrategy et une méthode ExecuteStrategy qui lance la méthode Process() de la stratégie.

Ok, Alors dernière suggestion :zoubi:

Code:

---

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

public static class DataMiningProcess {   public static IList<Item> Process(this IDataMiningStrategy strategy, String param1, String param2) { strategy.PreProcess(); IList<Item> itemsList = new List<Item>(); strategy.PostProcess(); return itemsList; }   }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

public class ConcreteDataMiningStrategyProductX : IDataMiningStrategy { #region DataMiningStrategy Members   public override void PreProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PreProcess - This methode does nothing but who cares ?"); }   public override IList<Item> Process(String param1, String param2) { return this.Process(param1, param2); //DataMiningProcess.Process(this, param1, param2); }   public override void PostProcess() { Console.WriteLine("ConcreteDataMiningStrategy.PostProcess - This methode does nothing but who cares ?"); }   #endregion }

---

Je suis d'accord qu'on se rapproche de ce que tu avait proposé, mais ce qui me dérange c'est classe de base qui à les mêmes méthodes que l'interface sans pour autan l’implémenter.

Citation:

---

Envoyé par nevaram

Je suis d'accord qu'on se rapproche de ce que tu avait proposé, mais ce qui me dérange c'est classe de base qui à les mêmes méthodes que l'interface sans pour autan l’implémenter.

---

Je ne suis pas fan non plus, mais encore moins fan de la solution qui consiste à passer la stratégie en paramètre...

Pas sûr qu'il y ait une solution simple à ce problème en fait...

...ou alors je vais finir par admettre que DataMiningProcess doive implémenter l'interface DataMiningStrategy :(