Jusqu'où aller les méthodes, les propriétés, & # 8230; d'une classe de base, par ex. Classe .net TreeNode

Question

Je travaille sur une application qui utilise un contrôle TreeView pour représenter les objets métier. Actuellement, le lien entre les objets métier et TreeNodes est géré via la propriété Tag de TreeNode. Je ne suis pas très heureux avec cela, parce que je pense que le lien n'est pas "étroit" suffisant. Par exemple, il pourrait y avoir un objet TreeNode sans objet métier. Je souhaite également mettre à jour l'image TreeNode en fonction de l'état d'objet métier. C'est pourquoi j'ai dérivé ma propre classe spéciale TreeNode à partir de TreeNode:

class ActionTreeNode : TreeNode
   {
      private Action mAction;

      public Action Action
      { get ... }

      public ActionTreeNode(Action action)
         : base()
      {
         if (action == null) throw new ArgumentNullException("action", "Paramter action must not be null.");

         mAction = action;
      }

    public void UpdateState()
      {
         switch (mAction.ActionState)
         {
            case ActionState.Passed:
               SelectedImageIndex = 3;
               ImageIndex = 3;
               break;
            case ActionState.Failed:
               SelectedImageIndex = 2;
               ImageIndex = 2;
               break;
            ...
         }

         return;
      }
   }

Avec cette approche minimale, je dois lancer chaque fois que j'appelle une propriété ou une méthode de la classe de base qui retourne un objet TreeNode, comme dans "((ActionTreeNode) myNode.Parent". La solution serait de remplacer / écraser chaque méthode ou propriété et de renvoyer un objet de type ActionTreeNode. Que pensez-vous, est-il plus approprié d'adopter l'approche minimale ou prendriez-vous l'effort de réimplémenter toutes les méthodes, propriétés afin d'éviter de lancer? Merci.

Answer 1

J'aime l'approche minimale. Si vous craignez d'encombrer votre code de nombreuses instructions de conversion, créez simplement une méthode pour le faire pour vous au même endroit:

private ActionTreeNode GetParent(ActionTreeNode node)
{
    return node.Parent as ActionTreeNode;
}

// in some method:
ActionTreeNode parent = GetParent(someNode);
if (parent != null)
{
    // the parent is an ActionTreeNode
}

N'oubliez pas le contrôle null sur la valeur de retour si le parent ne doit pas être un ActionTreeNode ...

Answer 2

Je pense que la question est de savoir combien de temps cela prendra-t-il de faire l'effort de le faire fortement typé.

Pesez le coût de la création de "tout" "& serré" " avec le coût de vous et d'autres développeurs ayant une plate-forme solide pour travailler avec.

Sans en savoir plus, je pense personnellement que je l'emploierais avec force car cela signifierait également que tout changement dans votre logique métier, tel que différents types stockés dans l'arborescence, entraînerait un échec de compilation plutôt que d'éventuels bogues inconnus.