Refactorisation d'une classe de sélecteur de méthode

Je travaille sur du code existant. Après quelques heures, j'ai réduit ce problème à une classe de sélection de méthodes. Je trouve cette classe difficile à suivre. Est-il possible de réaliser ce type de méthode en choisissant la fonctionnalité d'une manière simple?Refactorisation d'une classe de sélecteur de méthode

public class MethodPicker 
    { 
     private delegate string SomeFunc(MethodPicker item); 

     static readonly Dictionary<string, SomeFunc> test = new Dictionary<string, SomeFunc>(); 

     static MethodPicker() 
     { 
      test.Add("key1", Func1); 
      test.Add("key2", Func2); 
      test.Add("key3", Func3); 
     } 

     public string RunTest(string Name) 
     { 
      string somestring = test[Name].Invoke(this); 
      return somestring; 
     } 

     public static string Func1(MethodPicker entity) 
     { 
      return "func1 runs"; 
     } 

     public static string Func2(MethodPicker entity) 
     { 
      return "func2 runs"; 
     } 

     public static string Func3(MethodPicker entity) 
     { 
      return "func3 runs"; 
     } 
    }

Source

2012-06-13 P.Brian.Mackey

Pouvez-vous expliquer ce que la classe est pour? Est-ce juste, "donné une chaîne, invoquer une méthode correspondante?" Si oui, comment cette logique devrait-elle être expliquée? Une cartographie peut-elle exister en tant qu'attribut sur les méthodes statiques? Sans vous expliquer comment cette classe est destinée à être utilisée, je pense qu'il sera difficile d'offrir une solution utile. –

Exactement ce que dit @KirkWoll. En dehors de ça, qu'est-ce que tu ne comprends pas exactement? Est-ce le «délégué» ou le «Invoke» (parce que c'est fondamentalement tout ce qui est «difficile» à propos de la classe). – Styxxy

Utilise les attributs de la méthode. Pas de manière plus simple mais légèrement évolutive. –

Eh bien, ce serait une solution plus simple ..

public class MethodPicker 
    { 
     public string RunTest(string Name) 
     { 
      string somestring; 
      if (Name.equals("key1") 
       return Func1(this); 
      else if(Name.equals("key2") 
       return Func2(this); 
      else if (Name.equals("key3") 
       return Func3(this); 
      else 
       throw new Exception(name + " not found.. "); 
     } 

     public static string Func1(MethodPicker entity) 
     { 
      return "func1 runs"; 
     } 

     public static string Func2(MethodPicker entity) 
     { 
      return "func2 runs"; 
     } 

     public static string Func3(MethodPicker entity) 
     { 
      return "func3 runs"; 
     } 
    }

Il met également en évidence ce qui est un problème potentiel dans la solution dictionnaire que vous avez pas d'erreur appropriée manipulation si la clé/nom n'existe pas dans le dictionnaire. Dans votre solution, il provoquerait une NullPointerException ici:

string somestring = test[Name].Invoke(this);

test[Name] serait return null ...

Source

2012-06-13 21:15:38 barsju

Je suppose * remplacer une solution générale par une solution inflexible qualifie de "plus simple". –

Je ne dis pas que je recommande cette solution, mais cela devrait aider à expliquer ce qui se passe. – barsju

j'ai décidé de cacher la complexité avec une nouvelle propriété et une méthode d'extension.

public class MethodPicker 
    { 
     public string Name {get;set;} 
    } 

public static class Extensions 
{  
     private delegate string SomeFunc(MethodPicker item); 
     static readonly Dictionary<string, SomeFunc> test = new Dictionary<string, SomeFunc>(); 

     static Extensions() 
     { 
      test.Add("key1", Func1); 
      test.Add("key2", Func2); 
      test.Add("key3", Func3); 
     } 

     public string AsSpecialString(this MethodPicker obj) 
     { 
      string somestring = test[obj.Name].Invoke(obj); 
      return somestring; 
     } 

     string Func1(MethodPicker entity) 
     { 
      return "func1 runs"; 
     } 

     static string Func2(MethodPicker entity) 
     { 
      return "func2 runs"; 
     } 

     static string Func3(MethodPicker entity) 
     { 
      return "func3 runs"; 
     } 
}

Source

2012-06-13 21:25:00

Refactorisation d'une classe de sélecteur de méthode

Répondre

Questions connexes