Até onde ir substituindo métodos, propriedades ... de uma classe base, por exemplo, classe .net TreeNode

Question

Eu estou trabalhando em algum aplicativo, que usa um controle TreeView para representar objetos de negócios. Atualmente, a ligação entre objetos de negócios e TreeNodes é mantida através da propriedade Tag do TreeNode. Im não muito feliz com isso, porque eu acho que o link não é "apertado" o suficiente. Por exemplo, pode haver um objeto TreeNode sem um objeto de negócios, também eu quero atualizar a imagem TreeNode dependendo do estado objact negócio. Portanto, eu derivado minha própria classe TreeNode especial do 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;
      }
   }

Com esta abordagem mínima tenho para lançar cada vez que eu chamar uma propriedade ou método da classe base, que retorna um objeto TreeNode como em "(ActionTreeNode) myNode.Parent". A solução seria a de substituir / substituir cada método ou propriedade e retornar um objeto do tipo ActionTreeNode. O que você acha, é mais adequado para assumir a abordagem mínima ou você fazer o esforço para reimplementar todos os métodos, propriedades, a fim de fundição evitar? Obrigado.

Answer 1

Eu gosto da abordagem mínima. Se você está preocupado com desordenar o seu código com cargas de declarações elenco simplesmente criar um método para fazer isso por você em um lugar:

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ão se esqueça do cheque nulo sobre o valor de retorno, porém, deve o pai não ser um ActionTreeNode ...

Answer 2

Eu acho que a questão é quanto tempo ele vai levá-lo para fazer o esforço para torná-lo fortemente tipado.

Pesar-se o custo de fazer everythign "apertado" com o custo de você e outros desenvolvedores com uma plataforma sólida para trabalhar.

Sem saber mais, eu pessoalmente acho que eu iria escrever sobre ele, uma vez que também significa que qualquer alteração à sua lógica de negócios, tais como diferentes tipos armazenados na árvore irá resultar em uma falha de compilação ao invés de possíveis erros desconhecidos.