OVH Cloud OVH Cloud

Réimplémentation d'une interface

14 réponses
Avatar
ShadowFil
Bonjour,

Question 1 :
Une classe qui hérite d'une implémentation d'interface peut réimplémenter
l'interface en l'incluant dans sa liste de classes de base.

Quel est l'intérêt de réimplémenter une interface ?

Question 2 :
Dans du code, on voit parfois une classe qui, dans sa déclaration, hérite
d'une classe de base et d'une interface, et que cette interface est déjà
implémentée par la classe de base. Mais pourtant, les méthodes de l'interface
ne sont pas réimplémenté dans la classe dérivée. Quel est l'intérêt dans ce
cas d'fériter à nouveau de l'interface ?

Par exemple :
interface IMyInterface
{ ... }

public class MyClassBase : IMyInterface
{ ... }

public class MyClassDerived : MyClassBase, IMyInterface
{ ... }


Merci pour votre aide.

10 réponses

1 2
Avatar
Simon Mourier [MS]
Q1:
pour changer l'implémentation?

Q2:
ça n'a pas grand intêret, sauf éventuellement pour des outils où des
programmes qui seraient basés sur des mécanismes d'introspection
(=reflexion) et qui s'arrêteraient au niveau d'une classe sans scruter les
classes de base

Simon.
"ShadowFil" a écrit dans le message de
news:
Bonjour,

Question 1 :
Une classe qui hérite d'une implémentation d'interface peut réimplémenter
l'interface en l'incluant dans sa liste de classes de base.

Quel est l'intérêt de réimplémenter une interface ?

Question 2 :
Dans du code, on voit parfois une classe qui, dans sa déclaration, hérite
d'une classe de base et d'une interface, et que cette interface est déjà
implémentée par la classe de base. Mais pourtant, les méthodes de
l'interface
ne sont pas réimplémenté dans la classe dérivée. Quel est l'intérêt dans
ce
cas d'fériter à nouveau de l'interface ?

Par exemple :
interface IMyInterface
{ ... }

public class MyClassBase : IMyInterface
{ ... }

public class MyClassDerived : MyClassBase, IMyInterface
{ ... }


Merci pour votre aide.


Avatar
ShadowFil
Q1:
D'accord mais, il existe déjà des mécanismes pour modifier une
implémentation : new ou override. Si la classe de base implémente déjà un
interface mais qu'on veut modifier cette implémentation, il suffit de
substituer ou masquer les implémentations existantes. Alors pourquoi ce
mécanisme supplémentaire ?

"Simon Mourier [MS]" a écrit :

Q1:
pour changer l'implémentation?

Q2:
ça n'a pas grand intêret, sauf éventuellement pour des outils où des
programmes qui seraient basés sur des mécanismes d'introspection
(=reflexion) et qui s'arrêteraient au niveau d'une classe sans scruter les
classes de base

Simon.
"ShadowFil" a écrit dans le message de
news:
> Bonjour,
>
> Question 1 :
> Une classe qui hérite d'une implémentation d'interface peut réimplémenter
> l'interface en l'incluant dans sa liste de classes de base.
>
> Quel est l'intérêt de réimplémenter une interface ?
>
> Question 2 :
> Dans du code, on voit parfois une classe qui, dans sa déclaration, hérite
> d'une classe de base et d'une interface, et que cette interface est déjà
> implémentée par la classe de base. Mais pourtant, les méthodes de
> l'interface
> ne sont pas réimplémenté dans la classe dérivée. Quel est l'intérêt dans
> ce
> cas d'fériter à nouveau de l'interface ?
>
> Par exemple :
> interface IMyInterface
> { ... }
>
> public class MyClassBase : IMyInterface
> { ... }
>
> public class MyClassDerived : MyClassBase, IMyInterface
> { ... }
>
>
> Merci pour votre aide.





Avatar
Simon Mourier [MS]
override ne fonctionne que si la classe de base le permet. quand à new, il
marche avec tout type de fonction.

La palette est juste riche et permet une certaine souplesse en fonction de
ses besoins. L'avantage des interfaces en .NET, c'est qu'une classe peut
implémenter plusieurs interfaces, alors qu'elle ne peut dériver que d'une
seule classe (abstraite ou pas).
Simon.


"ShadowFil" a écrit dans le message de
news:
Q1:
D'accord mais, il existe déjà des mécanismes pour modifier une
implémentation : new ou override. Si la classe de base implémente déjà un
interface mais qu'on veut modifier cette implémentation, il suffit de
substituer ou masquer les implémentations existantes. Alors pourquoi ce
mécanisme supplémentaire ?

"Simon Mourier [MS]" a écrit :

Q1:
pour changer l'implémentation?

Q2:
ça n'a pas grand intêret, sauf éventuellement pour des outils où des
programmes qui seraient basés sur des mécanismes d'introspection
(=reflexion) et qui s'arrêteraient au niveau d'une classe sans scruter
les
classes de base

Simon.
"ShadowFil" a écrit dans le message
de
news:
> Bonjour,
>
> Question 1 :
> Une classe qui hérite d'une implémentation d'interface peut
> réimplémenter
> l'interface en l'incluant dans sa liste de classes de base.
>
> Quel est l'intérêt de réimplémenter une interface ?
>
> Question 2 :
> Dans du code, on voit parfois une classe qui, dans sa déclaration,
> hérite
> d'une classe de base et d'une interface, et que cette interface est
> déjà
> implémentée par la classe de base. Mais pourtant, les méthodes de
> l'interface
> ne sont pas réimplémenté dans la classe dérivée. Quel est l'intérêt
> dans
> ce
> cas d'fériter à nouveau de l'interface ?
>
> Par exemple :
> interface IMyInterface
> { ... }
>
> public class MyClassBase : IMyInterface
> { ... }
>
> public class MyClassDerived : MyClassBase, IMyInterface
> { ... }
>
>
> Merci pour votre aide.







Avatar
ShadowFil
Ok.
Donc, je pense que c'est plus propre d'hériter qu'une seule fois d'une même
interface dans toute une lignée d'héritage. Car si on crée un diagramme de
classes UML avec plusieurs classes d'une même lignée d'héritage qui pointent
vers la même interface, c'est assez moche. Mais surtout, on a l'impression
que ce n'est pas optimisé.

"Simon Mourier [MS]" a écrit :

override ne fonctionne que si la classe de base le permet. quand à new, il
marche avec tout type de fonction.

La palette est juste riche et permet une certaine souplesse en fonction de
ses besoins. L'avantage des interfaces en .NET, c'est qu'une classe peut
implémenter plusieurs interfaces, alors qu'elle ne peut dériver que d'une
seule classe (abstraite ou pas).
Simon.


"ShadowFil" a écrit dans le message de
news:
> Q1:
> D'accord mais, il existe déjà des mécanismes pour modifier une
> implémentation : new ou override. Si la classe de base implémente déjà un
> interface mais qu'on veut modifier cette implémentation, il suffit de
> substituer ou masquer les implémentations existantes. Alors pourquoi ce
> mécanisme supplémentaire ?
>
> "Simon Mourier [MS]" a écrit :
>
>> Q1:
>> pour changer l'implémentation?
>>
>> Q2:
>> ça n'a pas grand intêret, sauf éventuellement pour des outils où des
>> programmes qui seraient basés sur des mécanismes d'introspection
>> (=reflexion) et qui s'arrêteraient au niveau d'une classe sans scruter
>> les
>> classes de base
>>
>> Simon.
>> "ShadowFil" a écrit dans le message
>> de
>> news:
>> > Bonjour,
>> >
>> > Question 1 :
>> > Une classe qui hérite d'une implémentation d'interface peut
>> > réimplémenter
>> > l'interface en l'incluant dans sa liste de classes de base.
>> >
>> > Quel est l'intérêt de réimplémenter une interface ?
>> >
>> > Question 2 :
>> > Dans du code, on voit parfois une classe qui, dans sa déclaration,
>> > hérite
>> > d'une classe de base et d'une interface, et que cette interface est
>> > déjà
>> > implémentée par la classe de base. Mais pourtant, les méthodes de
>> > l'interface
>> > ne sont pas réimplémenté dans la classe dérivée. Quel est l'intérêt
>> > dans
>> > ce
>> > cas d'fériter à nouveau de l'interface ?
>> >
>> > Par exemple :
>> > interface IMyInterface
>> > { ... }
>> >
>> > public class MyClassBase : IMyInterface
>> > { ... }
>> >
>> > public class MyClassDerived : MyClassBase, IMyInterface
>> > { ... }
>> >
>> >
>> > Merci pour votre aide.
>>
>>
>>





Avatar
Simon Mourier [MS]
Tout dépend si on veut privilégier le design - UML - ou la plateforme - .NET
/ c#. Ca peut être triste de se couper de fonctions de la plateforme pour
avoir un design plus "joli". Ma remarque est générale :-)

Simon.

"ShadowFil" a écrit dans le message de
news:
Ok.
Donc, je pense que c'est plus propre d'hériter qu'une seule fois d'une
même
interface dans toute une lignée d'héritage. Car si on crée un diagramme de
classes UML avec plusieurs classes d'une même lignée d'héritage qui
pointent
vers la même interface, c'est assez moche. Mais surtout, on a l'impression
que ce n'est pas optimisé.

"Simon Mourier [MS]" a écrit :

override ne fonctionne que si la classe de base le permet. quand à new,
il
marche avec tout type de fonction.

La palette est juste riche et permet une certaine souplesse en fonction
de
ses besoins. L'avantage des interfaces en .NET, c'est qu'une classe peut
implémenter plusieurs interfaces, alors qu'elle ne peut dériver que d'une
seule classe (abstraite ou pas).
Simon.


"ShadowFil" a écrit dans le message
de
news:
> Q1:
> D'accord mais, il existe déjà des mécanismes pour modifier une
> implémentation : new ou override. Si la classe de base implémente déjà
> un
> interface mais qu'on veut modifier cette implémentation, il suffit de
> substituer ou masquer les implémentations existantes. Alors pourquoi ce
> mécanisme supplémentaire ?
>
> "Simon Mourier [MS]" a écrit :
>
>> Q1:
>> pour changer l'implémentation?
>>
>> Q2:
>> ça n'a pas grand intêret, sauf éventuellement pour des outils où des
>> programmes qui seraient basés sur des mécanismes d'introspection
>> (=reflexion) et qui s'arrêteraient au niveau d'une classe sans scruter
>> les
>> classes de base
>>
>> Simon.
>> "ShadowFil" a écrit dans le
>> message
>> de
>> news:
>> > Bonjour,
>> >
>> > Question 1 :
>> > Une classe qui hérite d'une implémentation d'interface peut
>> > réimplémenter
>> > l'interface en l'incluant dans sa liste de classes de base.
>> >
>> > Quel est l'intérêt de réimplémenter une interface ?
>> >
>> > Question 2 :
>> > Dans du code, on voit parfois une classe qui, dans sa déclaration,
>> > hérite
>> > d'une classe de base et d'une interface, et que cette interface est
>> > déjà
>> > implémentée par la classe de base. Mais pourtant, les méthodes de
>> > l'interface
>> > ne sont pas réimplémenté dans la classe dérivée. Quel est l'intérêt
>> > dans
>> > ce
>> > cas d'fériter à nouveau de l'interface ?
>> >
>> > Par exemple :
>> > interface IMyInterface
>> > { ... }
>> >
>> > public class MyClassBase : IMyInterface
>> > { ... }
>> >
>> > public class MyClassDerived : MyClassBase, IMyInterface
>> > { ... }
>> >
>> >
>> > Merci pour votre aide.
>>
>>
>>







Avatar
Patrick Philippot
ShadowFil wrote:
Quel est l'intérêt de réimplémenter une interface ?



Bonjour,

L'intérêt est assez évident quand il s'agit d'une interface au travers
de laquelle le système va vous rendre un service particulier. Prenons le
cas des Collections et des interfaces IComparable et / ou IComparer.
C'est l'implémentation que vous fournissez pour cette interface qui va
déterminer la manière dont une collection va trier les objets qu'elle
contient. Il est parfaitement légitime d'imaginer que 2 classes qui
héritent l'une de l'autre fournissent 2 implémentations différentes de
ces interfaces de manière à ce que les objets qu'elles représentent
soient triés de manière différente par une même classe collection.

C'est même, dans le cas cité, le but du jeu. Il y a dans le framework de
nombreux cas similaires.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avatar
ShadowFil
Oui, mais dans ce cas, si on a besoin de polymorphisme, on utilise comme
d'habitude, les méthodes virtuelles. La classe de base fournit la première
implémentation de l'interface, en utilisant le mot-clé "virtual" pour les
méthodes de l'interface. Ainsi, les clases dérivées pourront substituer
l'implémentation des méthodes de l'interface avec leur propre implémentation.

On respecte ainsi le principe d'héritage, c'est-à dire qu'on hérite une
seule fois d 'une classe ou d'une interface. Comme dans la vie, on ne peut
hériter une chose qu'une seule fois.
Avatar
Patrick Philippot
ShadowFil wrote:
Oui, mais dans ce cas, si on a besoin de polymorphisme, on utilise
comme d'habitude, les méthodes virtuelles.



Effectivement, il vaut mieux aborder les choses en priorité de cette
manière. En fait, je suis un peu "biaisé" car je continue d'enseigner en
même temps VB6 et VB .Net (entre autres) et en VB6, évidemment, les
méthodes virtuelles et l'héritage, on ne connaît pas. On est obligé de
réimplémenter à chaque fois.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avatar
ShadowFil
Ce n'est pas seulement pour faire joli. C'est surtout pour faire en sorte de
respecter le principe d'héritage : comme dans le vie, on ne peut hériter
quelque chose qu'une seule fois. Donc, hériter plusieurs fois d'une même
interface dans la même lignée d'héritage, je trouve ça un choquant, pas
normal.

Si on a besoin de polymorphisme, on utilise comme
d'habitude, les méthodes virtuelles. La classe de base fournit la première
implémentation de l'interface, en utilisant le mot-clé "virtual" pour les
méthodes de l'interface. Ainsi, les clases dérivées pourront substituer
l'implémentation des méthodes de l'interface avec leur propre implémentation.
C'est quand même plus propre.

Peut-être que cette possibilité supplémentaire de réimplémentation
d'interface n'existe que pour des languages autre que C#, comme VB, qui ne
permettent pas le polymorphisme ?
Avatar
Simon Mourier [MS]
Ne pas oublier que le .NET Framework ne prend en charge qu'une seule classe
de base au maximum. Ce qui change tout fondamentalement
Simon.

"ShadowFil" a écrit dans le message de
news:
Oui, mais dans ce cas, si on a besoin de polymorphisme, on utilise comme
d'habitude, les méthodes virtuelles. La classe de base fournit la première
implémentation de l'interface, en utilisant le mot-clé "virtual" pour les
méthodes de l'interface. Ainsi, les clases dérivées pourront substituer
l'implémentation des méthodes de l'interface avec leur propre
implémentation.

On respecte ainsi le principe d'héritage, c'est-à dire qu'on hérite une
seule fois d 'une classe ou d'une interface. Comme dans la vie, on ne peut
hériter une chose qu'une seule fois.


1 2