Différence précise entre virtual / override et new

Version imprimable

31/03/2011, 21h10
Ikki_2504

Différence précise entre virtual / override et new

Bonjour à tous,

J'essaye depuis quelques heures de comprendre le différence *exacte* les mots clefs virtual (qui semble aller de pair avec override) et new.

Je prends un exemple de msdn : http://msdn.microsoft.com/fr-fr/libr...=vs.80%29.aspx
Ils illustrent ici l'utilisation du mot cle override. Je pense l'avoir bien compris, rien de bien complexe.

Seulement, lorsque j'apporte les modifs suivantes :
- J'enlève le mot clef virtual de la méthode CalculatePay() dans la classe Employee
- Je remplace public override decimal CalculatePay() par public new decimal CalculatePay() dans la classe SalesEmployee (qui hérite d'Employee)

...

Le résultat est strictement identique...

Après avoir arpenté pas mal de sites web, j'ai vu que l'utilisation de new était déconseillée... Mais j'ai pas vraiment compris pourquoi.

Quelqu'un aurait-il une explication ou un exemple afin que je comprenne clairement ?

D'avance merci :)

Bonsoir,

Ce n'est pas du tout pareil !
Un exemple pour illustrer la chose :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
public class Entity
    {
        public virtual void Execute()
        {
            Console.WriteLine("salut, je suis dans entity");
        }
 
        public void Execute2()
        {
            Console.WriteLine("salut, je suis dans entity");
        }
    }

Code:

1
2
3
4
5
6
7
8
9
10
11
12
public class Human : Entity
    {
        public override void Execute()
        {
            Console.WriteLine("salut, je suis dans Human");
        }
 
        public new void Execute2()
        {
            Console.WriteLine("salut, je suis dans Human");
        }
    }

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
class Program
    {
        static void Main(string[] args)
        {
            Entity human = new Human();
 
            human.Execute(); // => Je suis dans Human
 
            human.Execute2(); // => Je suis dans Entity
 
            Console.Read();
        }      
    }

Ici on caste notre "Human" en Entity.
Dans le cas n°1, celui de l'override, la classe Human à écrasé la méthode de la classe Entity, comme tu peut le voir, c'est donc la méthode de Human qui est appelé.
Dans le cas n°2 avec new, la méthode de la classe Entity n'a pas était écrasé, c'est donc celle-ci qui est appelé. "new" ne fait que cacher la méthode de Entity dans la classe Human.

Pour compléter l'explication de Jerede :

La différence est en fait liée au polymorphisme. Quand tu overrides dans une classe Derived une méthode virtual M définie dans une classe Base, tu redéfinis son implémentation : ça reste la même méthode, mais c'est l'implémentation spécifique de la classe courante qui sera appelée. Si tu as une variable x de type Base qui fait référence à une instance de la classe Derived, x.M() fera appel à Derived.M() et non à Base.M().

Quand tu fais un new sur une méthode, tu caches l'implémentation de la classe de base. Ca introduit une nouvelle méthode, qui n'a pas de lien avec la méthode de même nom de la classe de base. Cette méthode ne participe pas au polymorphisme, et sera appelée seulement via une variable de la classe dérivée. Pour reprendre l'exemple précédent, x.M() appelera Base.M(), pas Derived.M() (toujours en supposant que x est déclarée de type Base)

Je reprends l'exemple de Jerede en le complétant un peu :
Code:

1 2 3 4 5 6 7 8 9 Human human = new Human(); Entity entity = human; entity.Execute(); // => Je suis dans Human human.Execute(); // => Je suis dans Human entity.Execute2(); // => Je suis dans Entity human.Execute2(); // => Je suis dans Human
On voit bien que dans le cas de la méthode virtuelle, c'est toujours l'implémentation de Human qui est appelée, même à partir d'une variable de type Entity.

En revanche, les appels à Execute2 (non virtuelle) appellent en fait 2 méthodes différentes, selon le type de la variable, bien que les 2 variables fassent référence au même objet

Si l'utilisation de new est déconseillée, c'est parce que si tu manipules l'objet via une variable de la classe de base, ta méthode redéfinie avec new ne sera pas appelée. Par exemple, dans un contrôle WinForms, si tu redéfinis OnPaint en faisant new au lieu de override, ta méthode ne sera pas appelée car l'appel est fait via une variable de type Control, et non le type de ton contrôle

Code:

1
2
3
4
5
6
7
8
9
            Human human = new Human();
            Entity entity = human;
 
            entity.Execute(); // => Je suis dans Human 
            human.Execute();  // => Je suis dans Human 
 
            entity.Execute2(); // => Je suis dans Entity
            human.Execute2(); // => Je suis dans Human

Petite coquille non? :D

01/04/2011, 10h17
tomlev

Citation:

Envoyé par Nathanael Marchand

Petite coquille non? :D

Oups :oops:
Merci, c'est corrigé ;)
01/04/2011, 14h50
Ikki_2504

Merci pour ces réponses illustrées, je crois que je commence à saisir le principe :)

En revanche, je vois pas dans quel(s) cas on a intérêt à écrire :

Code:

Entity human = new Human();

Je veux dire par là que je si veux créer une nouvelle instance de Human, j'aurai tendance à écrire tout simplement :

Code:

Human human = new Human();

Citation:

En revanche, je vois pas dans quel(s) cas on a intérêt à écrire ...

Dans ce cas par exemple :
Code:

1 2 3 4 5 6 7 8 9 Entity MyEntity=null ; Switch (SelectComboBox.text) { case "Human" : MyEntity=new Human () ; break ; case "Animal" : MyEntity=new Animal() ; break ; ... } MyEntity.Draw() ;

01/04/2011, 17h13
Ikki_2504

Mmmh, pas bête du tout ça, je n'y avais pas pensé !

Merci à tous pour vos réponses (rapides en plus !), je vais pratiquer un peu histoire d'être sur d'avoir bien compris :)
01/04/2011, 17h17
tomlev
Citation:

Envoyé par Ikki_2504

En revanche, je vois pas dans quel(s) cas on a intérêt à écrire :

Code:

Entity human = new Human();

Je veux dire par là que je si veux créer une nouvelle instance de Human, j'aurai tendance à écrire tout simplement :

Code:

Human human = new Human();

Sauf que selon les cas, tu ne voudras pas toujours créer le même type d'entité... (cf. l'exemple de Graffito)

Autre exemple : tu crées une méthode qui peut manipuler n'importe quel type d'entité :
Code:

1 2 3 4 5 6 public void DoSomething(Entity entity) { ... entity.Execute(); ... }
Là tu ne sais même pas de quel type d'entité il s'agit, mais tu n'as pas besoin de le savoir : Execute est virtuelle, donc ça appellera automatiquement l'implémentation du type réel. Alors que si tu avais appelé Execute2, ça aurait toujours appelé Entity.Execute2, jamais Human.Execute2, puisque Execute2 n'est pas virtuelle
01/04/2011, 17h59
Ikki_2504

Ok pour ton exemple tomlev

En essayant d'appliquer l'exemple de Graffito... J'ai fait un GetType() sur ma variable MyEntity selon le case dans lequel je passe, et effectivement, MyEntity est bien un Human ou un Animal :)

En revanche, je n'ai pas accès aux méthodes *spécifiques* d'Human ou d'Animal ; je n'ai accès qu'aux méthodes d'Entity... Est-ce normal ? Si oui pourquoi ? Une fois casté, un objet devrait avoir un accès complet aux méthodes de la classe dans laquelle il se trouve non ?
01/04/2011, 20h51
binoo

Citation:

Envoyé par Ikki_2504

En revanche, je n'ai pas accès aux méthodes *spécifiques* d'Human ou d'Animal ; je n'ai accès qu'aux méthodes d'Entity... Est-ce normal ? Si oui pourquoi ?

Oui. Et c'est d'ailleurs exactement l'explication de tomlev avec la méthode Execute2 (voir son dernier post). ;)

Citation:

Envoyé par Ikki_2504

Une fois casté, un objet devrait avoir un accès complet aux méthodes de la classe dans laquelle il se trouve non ?

Oui.
01/04/2011, 22h18
Nathanael Marchand
Citation:

Envoyé par Ikki_2504

Ok pour ton exemple tomlev

En essayant d'appliquer l'exemple de Graffito... J'ai fait un GetType() sur ma variable MyEntity selon le case dans lequel je passe, et effectivement, MyEntity est bien un Human ou un Animal :)

En revanche, je n'ai pas accès aux méthodes *spécifiques* d'Human ou d'Animal ; je n'ai accès qu'aux méthodes d'Entity... Est-ce normal ? Si oui pourquoi ? Une fois casté, un objet devrait avoir un accès complet aux méthodes de la classe dans laquelle il se trouve non ?

Tu peux toujours faire:
Code:

1 2 3 4 5 6 7 8 public void DoSomething(Entity entity) { ... if(entitiy is Human) (entity as Human).Execute2(); ... }
Dans ce cas la ca sera celle avec le new qui sera executé
Sacré noeud au cerveau hein?
02/04/2011, 22h07
Ikki_2504

Après avoir relu plusieurs fois vos différentes réponses ... Je commence à vraiment comprendre (je crois).

Effectivement, c'est loin d'être l'évidence même pour moi, mais j'y vois quand même une certaine logique...

Y'a pu qu'à (beaucoup) pratiquer pour que ça devienne naturel. :)

Merci encore pour vos réponses éclairées !