Détermination d'un type d'objet

Question

Encore une fois, j'espère vraiment que ce n'est pas une question d'opinion; J'essaie de savoir quelle est la meilleure façon de déterminer le type d'un objet qui appartient à une certaine hiérarchie en C#. J'ai deux façons de concevoir mon application:

1 - Utilisez une propriété sur la classe de base:

public abstract class Parent 
{ 
    public abstract TypeOfObject TypeOfObject { get; } 
} 

public class Child1 : Parent 
{ 
    public override TypeOfObject TypeOfObject { get { return TypeOfObject.Child1 } } 

    // ... 
} 

public class Child2 : Parent 
{ 
    public override TypeOfObject TypeOfObject { get { return TypeOfObject.Child2 } } 

    // ... 
} 

public enum TypeOfObject 
{ 
    Child1, 
    Child2 
} 

public static void Main() 
{ 
    Parent p = new Child1(); 

    switch (p.TypeOfObject) 
    { 
     case TypeOfObject.Child1: _doSomethingWithChild1(p);break; 
     case TypeOfObject.Child2: _doSomethingWithChild2(p);break; 
    } 
} 

2 - utiliser l'opérateur

public abstract class Parent 
{ 
    // ... 
} 

public class Child1 
{ 
    // ... 
} 


public class Child2 : Parent 
{  
    // ... 
} 

public enum TypeOfObject 
{ 
    Child1, 
    Child2 
} 

public static void Main() 
{ 
    Parent p = new Child1(); 

    if (p is Child1) _doSomethingWithChild1(p); 
    if (p is Child2) _doSomethingWithChild2(p); 
} 

Quels sont les implications de chaque alternative? Je pense que 2 a un plus grand impact sur les performances car il dépend des métadonnées, mais 1 semble beaucoup moins élégant. De plus, j'ai appris à faire ça en C++ ... Je ne suis pas sûr qu'il soit nécessaire de le faire avec C#.

EDIT 1:

J'ai ajouté le mot-clé override le code ci-dessus.

EDIT 2:

Je suis désolé, je l'ai sans doute pas moi-même clairement. Je vais illustrer mieux:

Par exemple, j'ai un objet WPF Panel qui possède une propriété Children, qui me retourne UIElement s. J'ai besoin de savoir de quel type un certain élément est capable d'agir ... Dans mon cas particulier, l'utilisateur dessine un graphique sur l'écran, donc j'ai besoin de savoir combien de nœuds et combien de connexions sont dessinées pour stocker puis à la base de données. Je ne peux malheureusement pas utiliser le polymorphisme pour ça, n'est-ce pas? Comment saurai-je si je devrais ajouter une ligne à ma table de nœuds ou à ma table de connexions?

Answer 1

Vos exemples d'utilisation sont faux (comme d'autres l'ont dit - utilisez le polymorphisme) mais il peut être raisonnable de demander de quel type est un objet.

j'ai posé une question similaire pour C++ Testing a c++ class for features

En ce qui concerne la différence entre # 1 et # 2. Les deux nécessitent des métadonnées. Dans le cas 1 vous le faites, dans le cas 2 vous utilisez de toute façon les métadonnées faites par le CLR. Le CLR est probablement meilleur que vous et paye de toute façon

Comme toujours - si vous voulez savoir lequel est le plus rapide, les réponses sont simples - mesurez-le et voyez. Je doute qu'il y ait une différence mesurable

Answer 2

la première alternative n'est pas nécessaire. Si vous regardez Object (la base de TOUS les objets en C#), vous trouverez un membre GetType().

Dans notre code de production, nous utilisons souvent la méthode 2, principalement pour "down-casting" qui est, jetant une classe de base à une classe qui est dérivée de ladite classe de base ...

if (myObject is Type1) dosomething(); 
if (myObject is Type2) dosomethingelse(); 

nous utilisons également l'opérateur as ....

Type1 object1 = someotherobject as type1; 
if (object1 != null) dosomething(); 

la bonne chose à ce sujet, est que vous n'obtiendrez des exceptions comme vous le feriez si vous avez essayé quelque chose comme ceci:

((TypeFoo)object1).bar(); // if object 1 is NOT of TypeFoo you get an exception 

Answer 3

Vous le faites mal ™. Jamais entendu parler de polymorphisme (liaison tardive/dynamique pour être plus précis)? Le parent devrait avoir une méthode abstraite comme doSomething() à être mis en œuvre par les enfants, tout ce qui était en _doSomethingWithChild1 devrait être en Child1.doSomething, etc .. C'est ce que OO est tous - bien, pas tous, mais en grande partie - à propos de! La FAQ C++ a raison de prétendre que C++ ne serait pas orienté objet sans virtual.Il est non seulement plus facile/moins susceptible d'ajouter un autre enfant (vous définissez simplement une nouvelle sous-classe et la méthode, pas besoin de manipuler les switchs ou les ifs) et très probablement le plus rapide possible (chaque JIT vaut polymorphic inline caching), il est aussi idiomatique et moins susceptible de vous donner ce regard "WTF";)