Bonjour , je voudrais savoir comment faire pour rendre les méthodes d'une
interface inaccessibles de l'extérieur. En C++ il est possible lorsqu'on
dérive de spécifier une visibilité. En C# cela est impossible, normal
puisque l'on peut dériver d'une seule classe et que l'on doit toujours
accès à la classe Object de base. Cependant lorsque l'on souhaite
implémenter une interface je ne comprend pas pourquoi on ne peut pas
implémenter les méthodes avec une visibilité réduite !
--------------------------------------------------------------------------
-------------------------------------
Exemple :
internal Interface ImyInterface // Ici "internal" permet de ne pas
montrer mon interface de l'exterieur, parfait !!!
{
void MafonctionTresPrivee(); // Impossible de mettre un private ou
internal ici, c plutôt normal
}
public class A, ImyInterface // Impossible de mettre un private
internal en implementant l'interface ici, c'est la logique du C#, Ok
j'accepte
{
public void MafonctionTresPrivee() // impossible de mettre la
surcharge en private ou internal !!! Erreur de compilateur ?
{
ASSERT(false);
}
}
public class B
{
A myObjectA = new A();
myObjectA .MafonctionTresPrivee(); // Et voila on peut accéder à
fonction !!!
}
--------------------------------------------------------------------------
------------------------------------
Bien sur il existe des bidouilles pour pouvoir masquer ces méthodes, comme
implémenter une 3eme classe.
Mais j'aimerais qqc de propre !
Merci d'avance
Bonjour , je voudrais savoir comment faire pour rendre les méthodes d'une
interface inaccessibles de l'extérieur. En C++ il est possible lorsqu'on
dérive de spécifier une visibilité. En C# cela est impossible, normal
puisque l'on peut dériver d'une seule classe et que l'on doit toujours
accès à la classe Object de base. Cependant lorsque l'on souhaite
implémenter une interface je ne comprend pas pourquoi on ne peut pas
implémenter les méthodes avec une visibilité réduite !
--------------------------------------------------------------------------
-------------------------------------
Exemple :
internal Interface ImyInterface // Ici "internal" permet de ne pas
montrer mon interface de l'exterieur, parfait !!!
{
void MafonctionTresPrivee(); // Impossible de mettre un private ou
internal ici, c plutôt normal
}
public class A, ImyInterface // Impossible de mettre un private
internal en implementant l'interface ici, c'est la logique du C#, Ok
j'accepte
{
public void MafonctionTresPrivee() // impossible de mettre la
surcharge en private ou internal !!! Erreur de compilateur ?
{
ASSERT(false);
}
}
public class B
{
A myObjectA = new A();
myObjectA .MafonctionTresPrivee(); // Et voila on peut accéder à
fonction !!!
}
--------------------------------------------------------------------------
------------------------------------
Bien sur il existe des bidouilles pour pouvoir masquer ces méthodes, comme
implémenter une 3eme classe.
Mais j'aimerais qqc de propre !
Merci d'avance
Bonjour , je voudrais savoir comment faire pour rendre les méthodes d'une
interface inaccessibles de l'extérieur. En C++ il est possible lorsqu'on
dérive de spécifier une visibilité. En C# cela est impossible, normal
puisque l'on peut dériver d'une seule classe et que l'on doit toujours
accès à la classe Object de base. Cependant lorsque l'on souhaite
implémenter une interface je ne comprend pas pourquoi on ne peut pas
implémenter les méthodes avec une visibilité réduite !
--------------------------------------------------------------------------
-------------------------------------
Exemple :
internal Interface ImyInterface // Ici "internal" permet de ne pas
montrer mon interface de l'exterieur, parfait !!!
{
void MafonctionTresPrivee(); // Impossible de mettre un private ou
internal ici, c plutôt normal
}
public class A, ImyInterface // Impossible de mettre un private
internal en implementant l'interface ici, c'est la logique du C#, Ok
j'accepte
{
public void MafonctionTresPrivee() // impossible de mettre la
surcharge en private ou internal !!! Erreur de compilateur ?
{
ASSERT(false);
}
}
public class B
{
A myObjectA = new A();
myObjectA .MafonctionTresPrivee(); // Et voila on peut accéder à
fonction !!!
}
--------------------------------------------------------------------------
------------------------------------
Bien sur il existe des bidouilles pour pouvoir masquer ces méthodes, comme
implémenter une 3eme classe.
Mais j'aimerais qqc de propre !
Merci d'avance
Mais j'aimerais qqc de propre !
Mais j'aimerais qqc de propre !
Mais j'aimerais qqc de propre !
void DoSomething();
}
public class MyClass : MyInterface {
public MyClass() {
}
void MyInterface.DoSomething() {
}
}
Laurent Vigne wrote:
> Mais j'aimerais qqc de propre !
Bonjour,
C'est déjà propre :-) . Paul a raison: vous mélangez héritage
d'interface et héritage d'implémentation.
A partir du moment où l'on déclare qu'une classe supporte une interface
particulière, non seulement on s'engage sur un contrat pour cette classe
et ses dérivées mais on met en oeuvre pour les clients un mécanisme de
polymorphisme. Ce que vous voulez faire, c'est le plus sûr moyen
d'empêcher le polymorphisme de fonctionner. Côté client, le code
appelant doit pouvoir être sûr qu'ayant une référence sur un objet de
type ImyInterface ou sur une dérivée d'une telle classe, il peut appeler
toute méthode de ImyInterface. C'est la base *fondamentale et
intangible* du polymorphisme. Or vous voulez casser cette mécanique. Pas
étonnant qu'on ne vous y aide pas... :-)
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
void DoSomething();
}
public class MyClass : MyInterface {
public MyClass() {
}
void MyInterface.DoSomething() {
}
}
Laurent Vigne wrote:
> Mais j'aimerais qqc de propre !
Bonjour,
C'est déjà propre :-) . Paul a raison: vous mélangez héritage
d'interface et héritage d'implémentation.
A partir du moment où l'on déclare qu'une classe supporte une interface
particulière, non seulement on s'engage sur un contrat pour cette classe
et ses dérivées mais on met en oeuvre pour les clients un mécanisme de
polymorphisme. Ce que vous voulez faire, c'est le plus sûr moyen
d'empêcher le polymorphisme de fonctionner. Côté client, le code
appelant doit pouvoir être sûr qu'ayant une référence sur un objet de
type ImyInterface ou sur une dérivée d'une telle classe, il peut appeler
toute méthode de ImyInterface. C'est la base *fondamentale et
intangible* du polymorphisme. Or vous voulez casser cette mécanique. Pas
étonnant qu'on ne vous y aide pas... :-)
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
void DoSomething();
}
public class MyClass : MyInterface {
public MyClass() {
}
void MyInterface.DoSomething() {
}
}
Laurent Vigne wrote:
> Mais j'aimerais qqc de propre !
Bonjour,
C'est déjà propre :-) . Paul a raison: vous mélangez héritage
d'interface et héritage d'implémentation.
A partir du moment où l'on déclare qu'une classe supporte une interface
particulière, non seulement on s'engage sur un contrat pour cette classe
et ses dérivées mais on met en oeuvre pour les clients un mécanisme de
polymorphisme. Ce que vous voulez faire, c'est le plus sûr moyen
d'empêcher le polymorphisme de fonctionner. Côté client, le code
appelant doit pouvoir être sûr qu'ayant une référence sur un objet de
type ImyInterface ou sur une dérivée d'une telle classe, il peut appeler
toute méthode de ImyInterface. C'est la base *fondamentale et
intangible* du polymorphisme. Or vous voulez casser cette mécanique. Pas
étonnant qu'on ne vous y aide pas... :-)
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Non, je ne mélange pas du tout et ce n'est pas une erreur de
modélisation / Conception. Mon interface est bien déclarée en
internal, et cela est voulu. Les assembly externes ont ainsi aucune
connaissance de cette interface et ne peuvent donc pratiquer de
polymorphisme.
Non, je ne mélange pas du tout et ce n'est pas une erreur de
modélisation / Conception. Mon interface est bien déclarée en
internal, et cela est voulu. Les assembly externes ont ainsi aucune
connaissance de cette interface et ne peuvent donc pratiquer de
polymorphisme.
Non, je ne mélange pas du tout et ce n'est pas une erreur de
modélisation / Conception. Mon interface est bien déclarée en
internal, et cela est voulu. Les assembly externes ont ainsi aucune
connaissance de cette interface et ne peuvent donc pratiquer de
polymorphisme.
Laurent Vigne wrote:
> Non, je ne mélange pas du tout et ce n'est pas une erreur de
> modélisation / Conception. Mon interface est bien déclarée en
> internal, et cela est voulu. Les assembly externes ont ainsi aucune
> connaissance de cette interface et ne peuvent donc pratiquer de
> polymorphisme.
A ce moment là, pourquoi ne pas faire de l'aggrégation ou du
containment? Au lieu d'avoir une classe qui dérive de ImyInterface,
implémentez une propriété privée qui est un objet appartenant à une
classe qui implémente ImyInterface et déléguez les appels à cet objet
quand c'est nécessaire.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Laurent Vigne wrote:
> Non, je ne mélange pas du tout et ce n'est pas une erreur de
> modélisation / Conception. Mon interface est bien déclarée en
> internal, et cela est voulu. Les assembly externes ont ainsi aucune
> connaissance de cette interface et ne peuvent donc pratiquer de
> polymorphisme.
A ce moment là, pourquoi ne pas faire de l'aggrégation ou du
containment? Au lieu d'avoir une classe qui dérive de ImyInterface,
implémentez une propriété privée qui est un objet appartenant à une
classe qui implémente ImyInterface et déléguez les appels à cet objet
quand c'est nécessaire.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Laurent Vigne wrote:
> Non, je ne mélange pas du tout et ce n'est pas une erreur de
> modélisation / Conception. Mon interface est bien déclarée en
> internal, et cela est voulu. Les assembly externes ont ainsi aucune
> connaissance de cette interface et ne peuvent donc pratiquer de
> polymorphisme.
A ce moment là, pourquoi ne pas faire de l'aggrégation ou du
containment? Au lieu d'avoir une classe qui dérive de ImyInterface,
implémentez une propriété privée qui est un objet appartenant à une
classe qui implémente ImyInterface et déléguez les appels à cet objet
quand c'est nécessaire.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
A partir du moment où l'on déclare qu'une classe supporte une interface
particulière, non seulement on s'engage sur un contrat pour cette classe
et ses dérivées mais on met en oeuvre pour les clients un mécanisme de
polymorphisme. Ce que vous voulez faire, c'est le plus sûr moyen
d'empêcher le polymorphisme de fonctionner. Côté client, le code
appelant doit pouvoir être sûr qu'ayant une référence sur un objet de
type ImyInterface ou sur une dérivée d'une telle classe, il peut appeler
toute méthode de ImyInterface. C'est la base *fondamentale et
intangible* du polymorphisme. Or vous voulez casser cette mécanique. Pas
étonnant qu'on ne vous y aide pas... :-)
A partir du moment où l'on déclare qu'une classe supporte une interface
particulière, non seulement on s'engage sur un contrat pour cette classe
et ses dérivées mais on met en oeuvre pour les clients un mécanisme de
polymorphisme. Ce que vous voulez faire, c'est le plus sûr moyen
d'empêcher le polymorphisme de fonctionner. Côté client, le code
appelant doit pouvoir être sûr qu'ayant une référence sur un objet de
type ImyInterface ou sur une dérivée d'une telle classe, il peut appeler
toute méthode de ImyInterface. C'est la base *fondamentale et
intangible* du polymorphisme. Or vous voulez casser cette mécanique. Pas
étonnant qu'on ne vous y aide pas... :-)
A partir du moment où l'on déclare qu'une classe supporte une interface
particulière, non seulement on s'engage sur un contrat pour cette classe
et ses dérivées mais on met en oeuvre pour les clients un mécanisme de
polymorphisme. Ce que vous voulez faire, c'est le plus sûr moyen
d'empêcher le polymorphisme de fonctionner. Côté client, le code
appelant doit pouvoir être sûr qu'ayant une référence sur un objet de
type ImyInterface ou sur une dérivée d'une telle classe, il peut appeler
toute méthode de ImyInterface. C'est la base *fondamentale et
intangible* du polymorphisme. Or vous voulez casser cette mécanique. Pas
étonnant qu'on ne vous y aide pas... :-)
void DoSomething();
}
public class MyClass : MyInterface {
public MyClass() {
}
void MyInterface.DoSomething() {
}
}
Bonjour , je voudrais savoir comment faire pour rendre les méthodes d'une
interface inaccessibles de l'extérieur. En C++ il est possible lorsqu'on
dérive de spécifier une visibilité. En C# cela est impossible, normal
puisque l'on peut dériver d'une seule classe et que l'on doit toujours
accès à la classe Object de base. Cependant lorsque l'on souhaite
implémenter une interface je ne comprend pas pourquoi on ne peut pas
implémenter les méthodes avec une visibilité réduite !
--------------------------------------------------------------------------
-------------------------------------
Exemple :
internal Interface ImyInterface // Ici "internal" permet de ne pas
montrer mon interface de l'exterieur, parfait !!!
{
void MafonctionTresPrivee(); // Impossible de mettre un private ou
internal ici, c plutôt normal
}
public class A, ImyInterface // Impossible de mettre un private
internal en implementant l'interface ici, c'est la logique du C#, Ok
j'accepte
{
public void MafonctionTresPrivee() // impossible de mettre la
surcharge en private ou internal !!! Erreur de compilateur ?
{
ASSERT(false);
}
}
public class B
{
A myObjectA = new A();
myObjectA .MafonctionTresPrivee(); // Et voila on peut accéder à
fonction !!!
}
--------------------------------------------------------------------------
------------------------------------
Bien sur il existe des bidouilles pour pouvoir masquer ces méthodes, comme
implémenter une 3eme classe.
Mais j'aimerais qqc de propre !
Merci d'avance
void DoSomething();
}
public class MyClass : MyInterface {
public MyClass() {
}
void MyInterface.DoSomething() {
}
}
Bonjour , je voudrais savoir comment faire pour rendre les méthodes d'une
interface inaccessibles de l'extérieur. En C++ il est possible lorsqu'on
dérive de spécifier une visibilité. En C# cela est impossible, normal
puisque l'on peut dériver d'une seule classe et que l'on doit toujours
accès à la classe Object de base. Cependant lorsque l'on souhaite
implémenter une interface je ne comprend pas pourquoi on ne peut pas
implémenter les méthodes avec une visibilité réduite !
--------------------------------------------------------------------------
-------------------------------------
Exemple :
internal Interface ImyInterface // Ici "internal" permet de ne pas
montrer mon interface de l'exterieur, parfait !!!
{
void MafonctionTresPrivee(); // Impossible de mettre un private ou
internal ici, c plutôt normal
}
public class A, ImyInterface // Impossible de mettre un private
internal en implementant l'interface ici, c'est la logique du C#, Ok
j'accepte
{
public void MafonctionTresPrivee() // impossible de mettre la
surcharge en private ou internal !!! Erreur de compilateur ?
{
ASSERT(false);
}
}
public class B
{
A myObjectA = new A();
myObjectA .MafonctionTresPrivee(); // Et voila on peut accéder à
fonction !!!
}
--------------------------------------------------------------------------
------------------------------------
Bien sur il existe des bidouilles pour pouvoir masquer ces méthodes, comme
implémenter une 3eme classe.
Mais j'aimerais qqc de propre !
Merci d'avance
void DoSomething();
}
public class MyClass : MyInterface {
public MyClass() {
}
void MyInterface.DoSomething() {
}
}
Bonjour , je voudrais savoir comment faire pour rendre les méthodes d'une
interface inaccessibles de l'extérieur. En C++ il est possible lorsqu'on
dérive de spécifier une visibilité. En C# cela est impossible, normal
puisque l'on peut dériver d'une seule classe et que l'on doit toujours
accès à la classe Object de base. Cependant lorsque l'on souhaite
implémenter une interface je ne comprend pas pourquoi on ne peut pas
implémenter les méthodes avec une visibilité réduite !
--------------------------------------------------------------------------
-------------------------------------
Exemple :
internal Interface ImyInterface // Ici "internal" permet de ne pas
montrer mon interface de l'exterieur, parfait !!!
{
void MafonctionTresPrivee(); // Impossible de mettre un private ou
internal ici, c plutôt normal
}
public class A, ImyInterface // Impossible de mettre un private
internal en implementant l'interface ici, c'est la logique du C#, Ok
j'accepte
{
public void MafonctionTresPrivee() // impossible de mettre la
surcharge en private ou internal !!! Erreur de compilateur ?
{
ASSERT(false);
}
}
public class B
{
A myObjectA = new A();
myObjectA .MafonctionTresPrivee(); // Et voila on peut accéder à
fonction !!!
}
--------------------------------------------------------------------------
------------------------------------
Bien sur il existe des bidouilles pour pouvoir masquer ces méthodes, comme
implémenter une 3eme classe.
Mais j'aimerais qqc de propre !
Merci d'avance
pour completer la réponse de Paul, je vais la jouer cours de morale :
le principe qui consiste à dire "comment fait on en C# ce qu'on faisait en
C++" ne fait pas avancer les choses, ni pour vous, ni pour l'appli.
C++ offrait des possibilités qui favorisaient l'implantation au detriment
la conception. hors, il se trouve qu'une "bonne" conception conduit
à des perfs tout aussi bonnes, voire meilleures.
en clair, l'heritage protected et private, ça sert à nib, l'heritage
multiple d'implantation, c'est franchement pas la panacée.
l'idée, on ne le repetera jamais assez, c'est l'utilisation.
class A { public f() {...} }
class B : private A
{
public g() { A::f() ; }
}
va devenir
class B : object
{
public g() { detail.f() ; }
private A detail = new A() ;
}
ce qui permet de dériver A à volonté, en fournissant plusieurs f possibles
selon le cas, et de rendre A abstraite. autrement plus interessant non ?
jetter un oeil sur System.IO. l'idée des Writer et Reader est un exemple
concret. suffit de se souvenir de <iostream.h> pour comprendre la
superiorité du concept.
la transition n'est pas facile ou évidente (je l'ai faite), mais il y'a au
bout un bénéfice immense.
voila voila
pour completer la réponse de Paul, je vais la jouer cours de morale :
le principe qui consiste à dire "comment fait on en C# ce qu'on faisait en
C++" ne fait pas avancer les choses, ni pour vous, ni pour l'appli.
C++ offrait des possibilités qui favorisaient l'implantation au detriment
la conception. hors, il se trouve qu'une "bonne" conception conduit
à des perfs tout aussi bonnes, voire meilleures.
en clair, l'heritage protected et private, ça sert à nib, l'heritage
multiple d'implantation, c'est franchement pas la panacée.
l'idée, on ne le repetera jamais assez, c'est l'utilisation.
class A { public f() {...} }
class B : private A
{
public g() { A::f() ; }
}
va devenir
class B : object
{
public g() { detail.f() ; }
private A detail = new A() ;
}
ce qui permet de dériver A à volonté, en fournissant plusieurs f possibles
selon le cas, et de rendre A abstraite. autrement plus interessant non ?
jetter un oeil sur System.IO. l'idée des Writer et Reader est un exemple
concret. suffit de se souvenir de <iostream.h> pour comprendre la
superiorité du concept.
la transition n'est pas facile ou évidente (je l'ai faite), mais il y'a au
bout un bénéfice immense.
voila voila
pour completer la réponse de Paul, je vais la jouer cours de morale :
le principe qui consiste à dire "comment fait on en C# ce qu'on faisait en
C++" ne fait pas avancer les choses, ni pour vous, ni pour l'appli.
C++ offrait des possibilités qui favorisaient l'implantation au detriment
la conception. hors, il se trouve qu'une "bonne" conception conduit
à des perfs tout aussi bonnes, voire meilleures.
en clair, l'heritage protected et private, ça sert à nib, l'heritage
multiple d'implantation, c'est franchement pas la panacée.
l'idée, on ne le repetera jamais assez, c'est l'utilisation.
class A { public f() {...} }
class B : private A
{
public g() { A::f() ; }
}
va devenir
class B : object
{
public g() { detail.f() ; }
private A detail = new A() ;
}
ce qui permet de dériver A à volonté, en fournissant plusieurs f possibles
selon le cas, et de rendre A abstraite. autrement plus interessant non ?
jetter un oeil sur System.IO. l'idée des Writer et Reader est un exemple
concret. suffit de se souvenir de <iostream.h> pour comprendre la
superiorité du concept.
la transition n'est pas facile ou évidente (je l'ai faite), mais il y'a au
bout un bénéfice immense.
voila voila
> Transformer les héritages en agrégation, c'est se donner une grosse
limitation de la modélisation objet ! Et cela ne résout pas du tout mon
problème exposé !
Cependant il n'était pas du tout logique d'exposer de façon public les
méthodes qui implémentent une interface (surtout si celle-ci est déclarée
internal). Voir la solution du problème dans mon post plus bas.
> Transformer les héritages en agrégation, c'est se donner une grosse
limitation de la modélisation objet ! Et cela ne résout pas du tout mon
problème exposé !
Cependant il n'était pas du tout logique d'exposer de façon public les
méthodes qui implémentent une interface (surtout si celle-ci est déclarée
internal). Voir la solution du problème dans mon post plus bas.
> Transformer les héritages en agrégation, c'est se donner une grosse
limitation de la modélisation objet ! Et cela ne résout pas du tout mon
problème exposé !
Cependant il n'était pas du tout logique d'exposer de façon public les
méthodes qui implémentent une interface (surtout si celle-ci est déclarée
internal). Voir la solution du problème dans mon post plus bas.
