Stratégie Modèle avec chaque algorithme ayant une signature de méthode différente

Question

Je fais un refactor sur certains codes.

Nous avons une liste d'investisseurs avec des montants affectés à chacun. Le total des montants devrait être égal à un autre total, mais parfois il y a quelques centimes de différence, donc nous utilisons différents algorithmes pour attribuer ces différences à chaque investisseur.

Le code actuel est quelque chose comme ceci:

public void Round(IList<Investors> investors, Enum algorithm, [here goes a list of many parameters]) { 

    // some checks and logic here - OMMITED FOR BREVITY 

    // pick method given algorithm Enum 

    if (algoritm == Enum.Algorithm1) { 
     SomeStaticClass.Algorithm1(investors, remainders, someParameter1, someParameter2, someParameter3, someParameter4) 
    } else if (algoritm == Enum.Algorithm2) { 
    SomeStaticClass.Algorithm2(investors, remainders, someParameter3) 
    } 
} 

jusqu'à présent, nous avons seulement deux algorithmes. Je dois mettre en œuvre le troisième. J'ai eu la possibilité de refactoriser les implémentations existantes ainsi que de faire du code générique pour faire cette fonction pour de futurs algorithmes, peut-être personnalisés pour chaque client.

Ma première pensée était "ok, c'est un modèle de stratégie". Mais le problème que je vois est que les deux algorithmes reçoivent une liste de paramètres différente (sauf pour les deux premiers). Et les futurs algorithmes peuvent également recevoir une liste de paramètres différente. La seule chose dans "commun" est la liste des investisseurs et les restes.

Comment puis-je concevoir ceci afin d'avoir une interface plus propre? Je pensais

1. établissement d'une interface avec tous les paramètres possibles, et le partager entre toutes les implémentations.
2. Utilisation d'un objet avec tous les paramètres possibles en tant que propriétés et utilisation de cet objet générique dans le cadre de l'interface. I aurait 3 paramètres: La liste des investisseurs, l'objet restants, et un objet "paramètres". Mais dans ce cas, j'ai un problème similaire. Instancier chaque objet et remplir les propriétés requises dépend de l'algorithme (sauf si je les ai tous définis). I devrait utiliser une usine (ou quelque chose) pour l'instancier, en utilisant tous les paramètres de l'interface, ai-je raison? Je déplacerais le problème de trop de paramètres à cette «usine» ou peu importe.
3. Utilisation d'un objet dynamique au lieu d'un objet de type statique. Toujours présente les mêmes problèmes qu'avant, l'instanciation

J'ai aussi pensé à utiliser le modèle des visiteurs, mais comme je comprends, ce serait le cas si j'avais différents algorithmes pour différentes entités à utiliser, comme, une autre catégorie d'investisseurs. Donc, je ne pense pas que ce soit la bonne approche. Jusqu'ici, celui qui me convainc le plus est le second, même si je suis encore un peu réticent à ce sujet.

Des idées?

Merci

Answer 1

stratégie a différentes implémentations. C'est simple lorsque tous les Béton Stratégies exigent la même signature de type. Mais lorsque des implémentations concrètes commencent à demander des données différentes de Context, nous devons prendre un peu de recul en relaxant l'encapsulation ("breaking encapsulation" est connu inconvénient de la stratégie), soit on peut passer de Context aux stratégies en signature de méthode ou en fonction du constructeur sur combien est nécessaire. En utilisant des interfaces et en décomposant des arbres d'objets volumineux dans des confinements plus petits, nous pouvons restreindre l'accès à la plus grande partie de l'état Contexte.

Le code suivant illustre le paramètre de méthode de passage.

public class Context { 
     private String name; 
     private int id; 
     private double salary; 
     Strategy strategy; 
     void contextInterface(){ 
      strategy.algorithmInterface(this); 
     } 
     public String getName() { 
      return name; 
     } 
     public int getId() { 
      return id; 
     } 
     public double getSalary() { 
      return salary; 
     } 
    } 

    public interface Strategy { 
    // WE CAN NOT DECIDE COMMON SIGNATURE HERE 
    // AS ALL IMPLEMENTATIONS REQUIRE DIFF PARAMS 
    void algorithmInterface(Context context); 
    } 

    public class StrategyA implements Strategy{ 
     @Override 
     public void algorithmInterface(Context context) { 
      // OBSERVE HERE BREAKING OF ENCAPSULATION 
      // BY OPERATING ON SOMEBODY ELSE'S DATA 
      context.getName(); 
      context.getId(); 
     } 
    } 

    public class StrategyB implements Strategy{ 
     @Override 
     public void algorithmInterface(Context context) { 
      // OBSERVE HERE BREAKING OF ENCAPSULATION 
      // BY OPERATING ON SOMEBODY ELSE'S DATA 
      context.getSalary(); 
      context.getId(); 
     } 
    } 

Answer 2

D'accord, je pourrais aller dans la mauvaise direction ... mais il vous semble un peu bizarre que vous passer dans les arguments pour tous les algorithmes, et l'identifiant de l'algorithme à utiliser réellement. La fonction Round() ne devrait-elle pas idéalement obtenir ce dont elle a besoin pour fonctionner?

J'imagine que la fonction ronde invoque() pour ressembler à quelque chose comme:

if (something) 
    algToUse = Enum.Algorithm1; 
else 
    if (otherthing) 
     algToUse = Enum.Algorithm2; 
    else 
     algToUse = Enum.Algorithm3; 
Round(investors, remainder, algToUse, dayOfMonth, lunarCycle, numberOfGoblinsFound, etc); 

... si, au contraire, vous l'avez fait quelque chose comme ceci:

public abstract class RoundingAlgorithm 
{ 
    public abstract void PerformRounding(IList<Investors> investors, int remainders); 
} 
public class RoundingRandomly : RoundingAlgorithm 
{ 
    private int someNum; 
    private DateTime anotherParam; 
    public RoundingRandomly(int someNum, DateTime anotherParam) 
    { 
     this.someNum = someNum; 
     this.anotherParam = anotherParam; 
    } 
    public override void PerformRounding(IList<Investors> investors, int remainder) 
    { 
     // ... code ... 
    } 
} 
// ... and other subclasses of RoundingAlgorithm 

// ... later on: 
public void Round(IList<Investors> investors, RoundingAlgorithm roundingMethodToUse) 
{ 
    // ...your other code (checks, etc)... 

    roundingMethodToUse.Round(investors, remainders); 
}  

... et alors votre fonction précédente ressemble simplement à:

RoundingAlgorithm roundingMethod; 
if (something) 
    roundingMethod = new RoundingByStreetNum(1, "asdf", DateTime.Now); 
else 
    if (otherthing) 
     roundingMethod = new RoundingWithPrejudice(null); 
    else 
     roundingMethod = new RoundingDefault(1000); 
Round(investors, roundingMethod); 

.. En fait, au lieu de remplir cette valeur Enum, créez simplement un objet RoundingAlgorithm et passez-le à Round() à la place.