Comme se fait il que toutes les méthodes de l'interface IList n'apparaissent
pas dans la classe abstraite CollectionBase ? (dans l'explorateur d'objets
par exemple ou l'intellisense)
Comment est-ce possible sachant que si je crée une classe abstraite qui
hérite d'une interface je dois obligatoirement :
- soit déclarer abstract les méthodes et propriétés de l'interface
- soit implémenter les méthodes et propriétés de l'interface
Du moins c'est la réaction du compilateur...
Merci
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Simon Mourier [MS]
Elles sont implémentées sous la forme suivante (exemple pour IDispose):
public class Toto: IDispose { void IDispose.Dispose() { } }
et non
public class Toto: IDispose { public void Dispose() { } }
Dans le premier cas, l'intellisense ne montre pas Toto.Dispose(), dans le deuxième si.
Dans le deuxième cas, je peux écrire
Toto toto = new Toto(); toto.Dispose();
et compiler.
Dans le premier cas, je dois écrire
Toto toto = new Toto(); ((IDispose)toto).Dispose();
pour compiler.
Mais en terme d'implémentation, cela revient (~) au même. Simon.
"ThierryP" <thierry_paul(a_virer)@tele2.fr> a écrit dans le message de news:
Comme se fait il que toutes les méthodes de l'interface IList n'apparaissent pas dans la classe abstraite CollectionBase ? (dans l'explorateur d'objets par exemple ou l'intellisense) Comment est-ce possible sachant que si je crée une classe abstraite qui hérite d'une interface je dois obligatoirement : - soit déclarer abstract les méthodes et propriétés de l'interface - soit implémenter les méthodes et propriétés de l'interface Du moins c'est la réaction du compilateur... Merci
Elles sont implémentées sous la forme suivante (exemple pour IDispose):
public class Toto: IDispose
{
void IDispose.Dispose()
{
}
}
et non
public class Toto: IDispose
{
public void Dispose()
{
}
}
Dans le premier cas, l'intellisense ne montre pas Toto.Dispose(), dans le
deuxième si.
Dans le deuxième cas, je peux écrire
Toto toto = new Toto();
toto.Dispose();
et compiler.
Dans le premier cas, je dois écrire
Toto toto = new Toto();
((IDispose)toto).Dispose();
pour compiler.
Mais en terme d'implémentation, cela revient (~) au même.
Simon.
"ThierryP" <thierry_paul(a_virer)@tele2.fr> a écrit dans le message de news:
udiZwgZLFHA.508@TK2MSFTNGP12.phx.gbl...
Comme se fait il que toutes les méthodes de l'interface IList
n'apparaissent
pas dans la classe abstraite CollectionBase ? (dans l'explorateur d'objets
par exemple ou l'intellisense)
Comment est-ce possible sachant que si je crée une classe abstraite qui
hérite d'une interface je dois obligatoirement :
- soit déclarer abstract les méthodes et propriétés de l'interface
- soit implémenter les méthodes et propriétés de l'interface
Du moins c'est la réaction du compilateur...
Merci
Elles sont implémentées sous la forme suivante (exemple pour IDispose):
public class Toto: IDispose { void IDispose.Dispose() { } }
et non
public class Toto: IDispose { public void Dispose() { } }
Dans le premier cas, l'intellisense ne montre pas Toto.Dispose(), dans le deuxième si.
Dans le deuxième cas, je peux écrire
Toto toto = new Toto(); toto.Dispose();
et compiler.
Dans le premier cas, je dois écrire
Toto toto = new Toto(); ((IDispose)toto).Dispose();
pour compiler.
Mais en terme d'implémentation, cela revient (~) au même. Simon.
"ThierryP" <thierry_paul(a_virer)@tele2.fr> a écrit dans le message de news:
Comme se fait il que toutes les méthodes de l'interface IList n'apparaissent pas dans la classe abstraite CollectionBase ? (dans l'explorateur d'objets par exemple ou l'intellisense) Comment est-ce possible sachant que si je crée une classe abstraite qui hérite d'une interface je dois obligatoirement : - soit déclarer abstract les méthodes et propriétés de l'interface - soit implémenter les méthodes et propriétés de l'interface Du moins c'est la réaction du compilateur... Merci
Ambassadeur Kosh
à l'explication trés complete de Simon, je rajouterai une recommandation.
((IDisposable)toto).Dispose() compilera même si l'objet n'implante pas IDisposable. une traduction intermediaire permettra de tirer avantage de la compilation.
IDisposable disposable = toto ; disposable.Dispose() ;
ainsi cette expression ne compilera pas si IDisposable n'est pas implantée.
à l'explication trés complete de Simon, je rajouterai une recommandation.
((IDisposable)toto).Dispose() compilera même si l'objet n'implante pas
IDisposable.
une traduction intermediaire permettra de tirer avantage de la compilation.
IDisposable disposable = toto ;
disposable.Dispose() ;
ainsi cette expression ne compilera pas si IDisposable n'est pas implantée.
à l'explication trés complete de Simon, je rajouterai une recommandation.
((IDisposable)toto).Dispose() compilera même si l'objet n'implante pas IDisposable. une traduction intermediaire permettra de tirer avantage de la compilation.
IDisposable disposable = toto ; disposable.Dispose() ;
ainsi cette expression ne compilera pas si IDisposable n'est pas implantée.
ThierryP
Merci pour vos infos mais j'ai beau essayer cela ne reproduit pas le comportement de l'explorateur d'objets de VS. Par exemple, la méthode Add() n'apparaît pas dans la classe abstraite "CollectionBase" qui hérite pourtant de IList. J'ai crée une interface puis une classe abstraite qui en hérite en prenant soin comme vous l'indiquez de déclarer les méthodes et propriétés dans la classe abstraite avec le nom de l'interface devant. Résultat, ces méthodes et propriétés apparaissent quand même dans l'explorateur d'objet.
De plus, dans le cas de "CollectionBase" j'ai du mal à voir l'intérêt d'avoir masqué Add(), Contains(), IndexOf(), Insert() et Remove(). Cela empêche de voir facilement, lors du développement, les méthodes intéressantes à implémenter (par exemple pour créer une collection fortement typée).
Merci...
"Simon Mourier [MS]" a écrit dans le message de news:
Elles sont implémentées sous la forme suivante (exemple pour IDispose):
public class Toto: IDispose { void IDispose.Dispose() { } }
et non
public class Toto: IDispose { public void Dispose() { } }
Dans le premier cas, l'intellisense ne montre pas Toto.Dispose(), dans le deuxième si.
Dans le deuxième cas, je peux écrire
Toto toto = new Toto(); toto.Dispose();
et compiler.
Dans le premier cas, je dois écrire
Toto toto = new Toto(); ((IDispose)toto).Dispose();
pour compiler.
Mais en terme d'implémentation, cela revient (~) au même. Simon.
"ThierryP" <thierry_paul(a_virer)@tele2.fr> a écrit dans le message de
news:
> Comme se fait il que toutes les méthodes de l'interface IList > n'apparaissent > pas dans la classe abstraite CollectionBase ? (dans l'explorateur
d'objets
> par exemple ou l'intellisense) > Comment est-ce possible sachant que si je crée une classe abstraite qui > hérite d'une interface je dois obligatoirement : > - soit déclarer abstract les méthodes et propriétés de l'interface > - soit implémenter les méthodes et propriétés de l'interface > Du moins c'est la réaction du compilateur... > Merci > >
Merci pour vos infos mais j'ai beau essayer cela ne reproduit pas le
comportement de l'explorateur d'objets de VS.
Par exemple, la méthode Add() n'apparaît pas dans la classe abstraite
"CollectionBase" qui hérite pourtant de IList.
J'ai crée une interface puis une classe abstraite qui en hérite en prenant
soin comme vous l'indiquez de déclarer les méthodes et propriétés dans la
classe abstraite avec le nom de l'interface devant. Résultat, ces méthodes
et propriétés apparaissent quand même dans l'explorateur d'objet.
De plus, dans le cas de "CollectionBase" j'ai du mal à voir l'intérêt
d'avoir masqué Add(), Contains(), IndexOf(), Insert() et Remove(). Cela
empêche de voir facilement, lors du développement, les méthodes
intéressantes à implémenter (par exemple pour créer une collection fortement
typée).
Merci...
"Simon Mourier [MS]" <simonm@online.microsoft.com> a écrit dans le message
de news: u8zCcCaLFHA.576@TK2MSFTNGP15.phx.gbl...
Elles sont implémentées sous la forme suivante (exemple pour IDispose):
public class Toto: IDispose
{
void IDispose.Dispose()
{
}
}
et non
public class Toto: IDispose
{
public void Dispose()
{
}
}
Dans le premier cas, l'intellisense ne montre pas Toto.Dispose(), dans le
deuxième si.
Dans le deuxième cas, je peux écrire
Toto toto = new Toto();
toto.Dispose();
et compiler.
Dans le premier cas, je dois écrire
Toto toto = new Toto();
((IDispose)toto).Dispose();
pour compiler.
Mais en terme d'implémentation, cela revient (~) au même.
Simon.
"ThierryP" <thierry_paul(a_virer)@tele2.fr> a écrit dans le message de
news:
udiZwgZLFHA.508@TK2MSFTNGP12.phx.gbl...
> Comme se fait il que toutes les méthodes de l'interface IList
> n'apparaissent
> pas dans la classe abstraite CollectionBase ? (dans l'explorateur
d'objets
> par exemple ou l'intellisense)
> Comment est-ce possible sachant que si je crée une classe abstraite qui
> hérite d'une interface je dois obligatoirement :
> - soit déclarer abstract les méthodes et propriétés de l'interface
> - soit implémenter les méthodes et propriétés de l'interface
> Du moins c'est la réaction du compilateur...
> Merci
>
>
Merci pour vos infos mais j'ai beau essayer cela ne reproduit pas le comportement de l'explorateur d'objets de VS. Par exemple, la méthode Add() n'apparaît pas dans la classe abstraite "CollectionBase" qui hérite pourtant de IList. J'ai crée une interface puis une classe abstraite qui en hérite en prenant soin comme vous l'indiquez de déclarer les méthodes et propriétés dans la classe abstraite avec le nom de l'interface devant. Résultat, ces méthodes et propriétés apparaissent quand même dans l'explorateur d'objet.
De plus, dans le cas de "CollectionBase" j'ai du mal à voir l'intérêt d'avoir masqué Add(), Contains(), IndexOf(), Insert() et Remove(). Cela empêche de voir facilement, lors du développement, les méthodes intéressantes à implémenter (par exemple pour créer une collection fortement typée).
Merci...
"Simon Mourier [MS]" a écrit dans le message de news:
Elles sont implémentées sous la forme suivante (exemple pour IDispose):
public class Toto: IDispose { void IDispose.Dispose() { } }
et non
public class Toto: IDispose { public void Dispose() { } }
Dans le premier cas, l'intellisense ne montre pas Toto.Dispose(), dans le deuxième si.
Dans le deuxième cas, je peux écrire
Toto toto = new Toto(); toto.Dispose();
et compiler.
Dans le premier cas, je dois écrire
Toto toto = new Toto(); ((IDispose)toto).Dispose();
pour compiler.
Mais en terme d'implémentation, cela revient (~) au même. Simon.
"ThierryP" <thierry_paul(a_virer)@tele2.fr> a écrit dans le message de
news:
> Comme se fait il que toutes les méthodes de l'interface IList > n'apparaissent > pas dans la classe abstraite CollectionBase ? (dans l'explorateur
d'objets
> par exemple ou l'intellisense) > Comment est-ce possible sachant que si je crée une classe abstraite qui > hérite d'une interface je dois obligatoirement : > - soit déclarer abstract les méthodes et propriétés de l'interface > - soit implémenter les méthodes et propriétés de l'interface > Du moins c'est la réaction du compilateur... > Merci > >
Ambassadeur Kosh
class MyClass : CollectionBase { public void f() { IList list = base ; // ou this, comme vous le sentez list.Add... } }
mais dans ce cas precis, la meilleure façon de faire, c'est de passer par le membre List de la CollectionBase, qui répond exactement à ce "souci". en fait, il fallait prendre le temps de lire, parceque tout est dans le post de Simon...
voila voila
class MyClass : CollectionBase
{
public void f()
{
IList list = base ; // ou this, comme vous le sentez
list.Add...
}
}
mais dans ce cas precis, la meilleure façon de faire, c'est de passer par le
membre List de la CollectionBase, qui répond exactement à ce "souci".
en fait, il fallait prendre le temps de lire, parceque tout est dans le post
de Simon...
class MyClass : CollectionBase { public void f() { IList list = base ; // ou this, comme vous le sentez list.Add... } }
mais dans ce cas precis, la meilleure façon de faire, c'est de passer par le membre List de la CollectionBase, qui répond exactement à ce "souci". en fait, il fallait prendre le temps de lire, parceque tout est dans le post de Simon...
voila voila
ThierryP
Bonjour, Ces forums sont trés efficaces de par leur réactivité et je tire mon chapeau à tous les contributeurs. Mais (cela est propre à l'écrit rapide du Net) l'art de la synthèse tout en se faisant comprendre rapidement n'est pas aisé. Aussi arrive t-il trés frequemment qu'il faille poser plusieurs fois une même question, ce qui est parfois agaçant parce que l'on se demande si en face la personne a pris le temps de la lire... Tout comme il arrive que celui qui répond se pose la même question ;o) Je comprend que si vous pensez vraiment que je n'ai pas bien lu le post de Simon cela vous agace mais votre réponse ne fait qu'ajouter à la confusion. Cessons de porter des jugements de valeur du type "il fallait prendre le temps de lire", cela n'apporte rien et dégrade la communication. Bien evidemment qu'il faut utiliser "list" mais cela n'a rien à voir avec ma question surement mal formulée donc, mea culpa là dessus.
Ca tombe sur vous mais ça fait un moment que je voulais écrire ça :o) Encore un grand merci pour votre aide, c'était juste une remarque pour être plus efficace (j'espère ne pas être compris de travers ce coup ci :o)))))))))) Thierry.
"Ambassadeur Kosh" a écrit dans le message de news: #
class MyClass : CollectionBase { public void f() { IList list = base ; // ou this, comme vous le sentez list.Add... } }
mais dans ce cas precis, la meilleure façon de faire, c'est de passer par
le
membre List de la CollectionBase, qui répond exactement à ce "souci". en fait, il fallait prendre le temps de lire, parceque tout est dans le
post
de Simon...
voila voila
Bonjour,
Ces forums sont trés efficaces de par leur réactivité et je tire mon chapeau
à tous les contributeurs.
Mais (cela est propre à l'écrit rapide du Net) l'art de la synthèse tout en
se faisant comprendre rapidement n'est pas aisé.
Aussi arrive t-il trés frequemment qu'il faille poser plusieurs fois une
même question, ce qui est parfois agaçant parce que l'on se demande si en
face la personne a pris le temps de la lire...
Tout comme il arrive que celui qui répond se pose la même question ;o)
Je comprend que si vous pensez vraiment que je n'ai pas bien lu le post de
Simon cela vous agace mais votre réponse ne fait qu'ajouter à la confusion.
Cessons de porter des jugements de valeur du type "il fallait prendre le
temps de lire", cela n'apporte rien et dégrade la communication.
Bien evidemment qu'il faut utiliser "list" mais cela n'a rien à voir avec ma
question surement mal formulée donc, mea culpa là dessus.
Ca tombe sur vous mais ça fait un moment que je voulais écrire ça :o)
Encore un grand merci pour votre aide, c'était juste une remarque pour être
plus efficace (j'espère ne pas être compris de travers ce coup ci
:o))))))))))
Thierry.
"Ambassadeur Kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
news: #t2DZThLFHA.2604@TK2MSFTNGP10.phx.gbl...
class MyClass : CollectionBase
{
public void f()
{
IList list = base ; // ou this, comme vous le sentez
list.Add...
}
}
mais dans ce cas precis, la meilleure façon de faire, c'est de passer par
le
membre List de la CollectionBase, qui répond exactement à ce "souci".
en fait, il fallait prendre le temps de lire, parceque tout est dans le
Bonjour, Ces forums sont trés efficaces de par leur réactivité et je tire mon chapeau à tous les contributeurs. Mais (cela est propre à l'écrit rapide du Net) l'art de la synthèse tout en se faisant comprendre rapidement n'est pas aisé. Aussi arrive t-il trés frequemment qu'il faille poser plusieurs fois une même question, ce qui est parfois agaçant parce que l'on se demande si en face la personne a pris le temps de la lire... Tout comme il arrive que celui qui répond se pose la même question ;o) Je comprend que si vous pensez vraiment que je n'ai pas bien lu le post de Simon cela vous agace mais votre réponse ne fait qu'ajouter à la confusion. Cessons de porter des jugements de valeur du type "il fallait prendre le temps de lire", cela n'apporte rien et dégrade la communication. Bien evidemment qu'il faut utiliser "list" mais cela n'a rien à voir avec ma question surement mal formulée donc, mea culpa là dessus.
Ca tombe sur vous mais ça fait un moment que je voulais écrire ça :o) Encore un grand merci pour votre aide, c'était juste une remarque pour être plus efficace (j'espère ne pas être compris de travers ce coup ci :o)))))))))) Thierry.
"Ambassadeur Kosh" a écrit dans le message de news: #
class MyClass : CollectionBase { public void f() { IList list = base ; // ou this, comme vous le sentez list.Add... } }
mais dans ce cas precis, la meilleure façon de faire, c'est de passer par
le
membre List de la CollectionBase, qui répond exactement à ce "souci". en fait, il fallait prendre le temps de lire, parceque tout est dans le
post
de Simon...
voila voila
Ambassadeur Kosh
> Je comprend que si vous pensez vraiment que je n'ai pas bien lu le post de Simon cela vous agace mais votre réponse ne fait qu'ajouter à la confusion.
ne pensez pas que je suis agacé. il en faut un peu plus :o) j'essayais d'attirer votre attention sur le fait que cette "disparition" dans la classe abstraite est exactement liée à ce qu'il expliquait.
le mécanisme de "visibilité" est devenu plus complexe de nos jours. c'est cette notion d'implantation "explicite" et "implicite" est la clef.
Cessons de porter des jugements de valeur du type "il fallait prendre le temps de lire", cela n'apporte rien et dégrade la communication.
il ne s'agit pas de ça.
Bien evidemment qu'il faut utiliser "list" mais cela n'a rien à voir avec ma question surement mal formulée donc, mea culpa là dessus.
il faut, non ! c'est une façon de faire. il y'en a d'autres.
mais reprenons : si les membres de IList etaient visibles directement, toute personne dérivant de CollectionBase aurait la possibilité directe d'appliquer un Add(object), ce qui est un peu domage pour une liste fortement typée. on peut ainsi mélanger chiens et chats dans une liste de castors. notez bien qu'on peut le faire de toute façon par le biais de IList, mais au moins, ça a l'avantage de rendre l'action deliberée.
de nombreuses fois, j'ai pu observer que le mécanisme "implicit/explicit" venait compenser l'absence de genericité. voyez, c'est encore une autre façon de faire : utiliser un mécanisme différent !
et pour répondre à votre derniere question : CollectionBase est une implantation de IList. donc dans CollectionBase, this est directement consideré comme IList, et tous ses membres sont visibles. à l'interieur de la classe (ce qui est pratique) et par l'exterieur, ce qui est facheux.
la morale de cette histoire, c'est que l'heritage d'implantation, ça daube. voila voila.
> Je comprend que si vous pensez vraiment que je n'ai pas bien lu le post de
Simon cela vous agace mais votre réponse ne fait qu'ajouter à la
confusion.
ne pensez pas que je suis agacé. il en faut un peu plus :o)
j'essayais d'attirer votre attention sur le fait que cette "disparition"
dans la
classe abstraite est exactement liée à ce qu'il expliquait.
le mécanisme de "visibilité" est devenu plus complexe de nos jours.
c'est cette notion d'implantation "explicite" et "implicite" est la clef.
Cessons de porter des jugements de valeur du type "il fallait prendre le
temps de lire", cela n'apporte rien et dégrade la communication.
il ne s'agit pas de ça.
Bien evidemment qu'il faut utiliser "list" mais cela n'a rien à voir avec
ma
question surement mal formulée donc, mea culpa là dessus.
il faut, non ! c'est une façon de faire. il y'en a d'autres.
mais reprenons : si les membres de IList etaient visibles directement, toute
personne dérivant de CollectionBase aurait la possibilité directe
d'appliquer un Add(object), ce qui est un peu domage pour une liste
fortement typée. on peut ainsi mélanger chiens et chats dans une liste de
castors. notez bien qu'on peut le faire de toute façon par le biais de
IList, mais au moins, ça a l'avantage de rendre l'action deliberée.
de nombreuses fois, j'ai pu observer que le mécanisme "implicit/explicit"
venait compenser l'absence de genericité.
voyez, c'est encore une autre façon de faire : utiliser un mécanisme
différent !
et pour répondre à votre derniere question : CollectionBase est une
implantation de IList. donc dans CollectionBase, this est directement
consideré comme IList, et tous ses membres sont visibles. à l'interieur de
la classe (ce qui est pratique) et par l'exterieur, ce qui est facheux.
la morale de cette histoire, c'est que l'heritage d'implantation, ça daube.
voila voila.
> Je comprend que si vous pensez vraiment que je n'ai pas bien lu le post de Simon cela vous agace mais votre réponse ne fait qu'ajouter à la confusion.
ne pensez pas que je suis agacé. il en faut un peu plus :o) j'essayais d'attirer votre attention sur le fait que cette "disparition" dans la classe abstraite est exactement liée à ce qu'il expliquait.
le mécanisme de "visibilité" est devenu plus complexe de nos jours. c'est cette notion d'implantation "explicite" et "implicite" est la clef.
Cessons de porter des jugements de valeur du type "il fallait prendre le temps de lire", cela n'apporte rien et dégrade la communication.
il ne s'agit pas de ça.
Bien evidemment qu'il faut utiliser "list" mais cela n'a rien à voir avec ma question surement mal formulée donc, mea culpa là dessus.
il faut, non ! c'est une façon de faire. il y'en a d'autres.
mais reprenons : si les membres de IList etaient visibles directement, toute personne dérivant de CollectionBase aurait la possibilité directe d'appliquer un Add(object), ce qui est un peu domage pour une liste fortement typée. on peut ainsi mélanger chiens et chats dans une liste de castors. notez bien qu'on peut le faire de toute façon par le biais de IList, mais au moins, ça a l'avantage de rendre l'action deliberée.
de nombreuses fois, j'ai pu observer que le mécanisme "implicit/explicit" venait compenser l'absence de genericité. voyez, c'est encore une autre façon de faire : utiliser un mécanisme différent !
et pour répondre à votre derniere question : CollectionBase est une implantation de IList. donc dans CollectionBase, this est directement consideré comme IList, et tous ses membres sont visibles. à l'interieur de la classe (ce qui est pratique) et par l'exterieur, ce qui est facheux.
la morale de cette histoire, c'est que l'heritage d'implantation, ça daube. voila voila.
