refactor help - pattern de stratégie

Question

L'objet ici est de mettre à jour l'interface utilisateur. Je le fais normalement sur le client mais cette application utilise le code derrière. Quoi qu'il en soit, ma question est que j'essaie de nettoyer ces déclarations d'ailleurs et j'ai pensé que le schéma de stratégie pourrait être approprié. Je n'ai pas besoin de tout faire pour moi mais si vous pouviez me donner quelques conseils pour y aller. Est-ce que je crée d'abord une interface et ensuite chaque stratégie implémente l'interface? Les génériques sont-ils utiles ici? Quels types de méthodes devraient être dans l'interface? Toute chose pour me faire partir serait très appréciée.

if (someObject.Status == 'A') { 
        btnRecordCall.Enabled = false; 
        btnAddMailOrStatusAction.Enabled = false; 
        btnPayments.Enabled = false; 
        btnAddressMaint.Enabled = false; 
        btnFilter.Enabled = false; 
        btnAddCoverage.Enabled = false; 
        btnPolicyForms.Enabled = false; 
        lblIsArchived.Text = "********** THIS CLAIM HAS BEEN ARCHIVED **********"; 
       } else if (someObject.Status == 'D') { 
        btnRecordCall.Enabled = false; 
        btnAddMailOrStatusAction.Enabled = false; 
        btnPayments.Enabled = false; 
        btnAddressMaint.Enabled = false; 
        btnFilter.Enabled = false; 
        btnAddCoverage.Enabled = false; 
        btnPolicyForms.Enabled = false; 
        lblIsArchived.Text = "- De-archive Request Pending"; 
       } else { 
        btnRecordCall.Enabled = true; 
        btnAddMailOrStatusAction.Enabled = true; 
        btnPayments.Enabled = true; 
        btnAddressMaint.Enabled = true; 
        btnFilter.Enabled = true; 
        btnAddCoverage.Enabled = true; 
        btnPolicyForms.Enabled = true; 
        lblIsArchived.Text = ""; 
       } 

Merci, ~ ck

Answer 1

Eh bien d'abord, si vous allez utiliser le modèle de stratégie avec une interface que vous voudrez peut-être une interface comme celui-ci.

public interface IStrategyUI 
{ 
    void Execute(); 
} 

puis quelques classes pour votre logique

public class StatusAStrategy : IStrategyUI 
{ 
    public void Execute() 
    { 
     //implement 
    } 
} 

alors votre instruction if peut être une usine techniquement. Vous pouvez renvoyer cet objet en tant qu'interface et encapsuler l'instruction switch dans une autre méthode ou classe de fabrique.

Pour que vous puissiez l'utiliser comme ceci.

IStrategyUI logic = StrategyFactory.GetStrategy(status); 
logic.Execute(); 

À vous de choisir.

Aussi, je n'utilise pas de classe de confinement ici, mais vous pouvez si vous le souhaitez.

Vous pouvez également le faire avec des délégués.

classe de confinement

class StrategyHolder 
    { 
     public Action Strategy { get; set; } 

     public void Execute() 
     { 
      if(this.Strategy != null) 
       this.Strategy(); 
     } 
    } 

Méthodes de stratégie.

void EnableStatusA() 
{ 
    //do everything for status A 
} 

commutateur déclaration

StrategyHolder logic = new StrategyHolder(); 

switch(someObject.Status) 
    { 
     case 'A': logic.Strategy = EnableStatusA; 
       //etc etc 

    } 

return logic; 

Appelez ce de l'extérieur.

StrategyHolder logic = StrategyFactory.GetStrategy(status); 
logic.Execute(); 

Answer 2

Si tous les boutons obtiennent le même permettant quel que soit le statut, comme dans votre exemple, alors je vous cache pas que loin dans une liste de boutons et juste itérer sur eux. Ensuite, vos paramètres pour la stratégie se résument à un seul booléen et une chaîne - et il est assez facile de le faire n'importe où. S'il y a une plus grande complexité, alors différentes classes implémentant une interface qui définit les contrôles seraient dans l'ordre, éventuellement avec une superclasse abstraite qui contient la logique globale.

Answer 3

Je pense que ce que vous cherchez est lepatten. Ceci est similaire au modèle de stratégie, sauf que chaque objet Etat reçoit normalement une référence à l'objet contexte (dans notre cas, il s'agit du formulaire) lors de sa création. Cela permet aux différents états de faire des choses à l'objet de contexte en réponse aux événements.

Lors de la mise en œuvre d'un modèle d'état, il est souvent préférable de faire en sorte que chaque état séparé hérite d'une classe de base abstraite. La classe de base peut ensuite implémenter les opérations par défaut dans les méthodes virtuelles, puis il suffit de remplacer les opérations qui diffèrent pour chaque état.

public interface IFormState 
{ 
    void EnableDisableControls(); 
} 

public class DefaultState : IFormState 
{ 
    private MyForm context; 

    public DefaultState(MyForm context) 
    { 
     this.context = context; 
    } 

    protected MyForm Context 
    { 
     get 
     { 
      return this.context; 
     } 
    } 

    public virtual void EnableDisableControls() 
    { 
     this.context.btnRecordCall.Enabled = true; 
     this.context.btnAddMailOrStatusAction.Enabled = true; 
     this.context.btnPayments.Enabled = true; 
     this.context.btnAddressMaint.Enabled = true; 
     this.context.btnFilter.Enabled = true; 
     this.context.btnAddCoverage.Enabled = true; 
     this.context.btnPolicyForms.Enabled = true; 
     this.context.lblIsArchived.Text = ""; 
    } 
} 

public class StateA : DefaultState 
{ 
    public StateA(MyForm context) 
     : base(context) 
    { 
    } 

    public override void EnableDisableControls() 
    { 
     base.EnableDisableControls(); 

     this.Context.lblIsArchived.Text = "********** THIS CLAIM HAS BEEN ARCHIVED **********"; 
     // etc... 
    } 
}