Fino a che punto andare oltre i metodi, le proprietà, ... di una classe base, ad es. .net TreeNode class

Question

Sto lavorando ad alcune applicazioni che utilizzano un controllo TreeView per rappresentare oggetti business. Attualmente il collegamento tra oggetti business e TreeNodes viene gestito tramite la proprietà Tag di TreeNode. Non sono molto contento di questo, perché penso che il link non sia "stretto". abbastanza. Ad esempio, potrebbe esserci un oggetto TreeNode senza un oggetto business, inoltre voglio aggiornare l'immagine TreeNode a seconda dello stato dell'oggetto business. Pertanto ho derivato la mia classe TreeNode speciale da 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;
      }
   }

Con questo approccio minimo devo eseguire il cast ogni volta che chiamo una proprietà o un metodo della classe base che restituisce un oggetto TreeNode come in " (ActionTreeNode) myNode.Parent " ;. La soluzione sarebbe quella di sovrascrivere / sovrascrivere ogni metodo o proprietà e restituire un oggetto di tipo ActionTreeNode. Cosa ne pensi, è più appropriato adottare un approccio minimale o faresti lo sforzo di reimplementare tutti i metodi e le proprietà al fine di evitare il casting? Grazie.

Answer 1

Mi piace l'approccio minimale. Se sei preoccupato di ingombrare il tuo codice con un sacco di dichiarazioni sul cast, crea semplicemente un metodo per farlo per te in un unico posto:

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
}

Non dimenticare il controllo null sul valore restituito, tuttavia se il genitore non è un ActionTreeNode ...

Answer 2

Penso che la domanda sia: quanto tempo ci vorrà per impegnarti a renderlo fortemente tipizzato.

Pesare il costo per rendere tutto "stretto". con il costo di te e altri sviluppatori che hanno una solida piattaforma con cui lavorare.

Senza saperne di più, penso personalmente che lo scriverei fortemente poiché ciò significherebbe anche che eventuali modifiche alla logica aziendale come i diversi tipi memorizzati nella struttura comporteranno un errore di compilazione piuttosto che possibili bug sconosciuti.