Bonjour,
 
Petite question mais vaste sujet :
Pourquoi les méthodes implémentant une interface "internal" doivent être publiques ( et pas "internal" ) ?
 
Mon avis est que cela n'a aucun sens.
 
Un peu dans la même veine j'avais posté une autre question à laquelle je n'ai jamais vraiment trouvé de réponse ( à part : "bon bein c'est comme ça en C#" ).

 
Il n'y a absolument pas de restriction sur le sujet.
 
Une classe internal peut contenir des méthodes internal, private, protected ou public.
Une classe publique peut contenir des méthodes internal, private, protected ou public.
 
par contre, qu'entends tu par "Méthode implémentant une classe internal" ?

Je pense qu'il veut parler de ça :
 

internal interface IA
    {
        string Print(string chaine);
        string Print2(string chaine);
    }
 
    internal class A : IA
    {
        public string Print(string chaine)
        {
            return string.Format("¤{0}¤", chaine);
        }
    }

 
Effectivement, "Print2" dans ma classe A ne peut pas être autrement que public.
 
Mais c'est normal : une interface défini le contrat des interfaces d'une classe. A partir de là, c'est normal que ces interfaces soient obligatoirement publiques.
 
Par contre, vu que la classe qui dérive de l'interface peut être internal, y'a pas de souci, tes méthodes ont de toute façon la portée public qu'à l'intérieur de la portée internal...
 
Mais imagine que la classe soit publique. Si les méthodes héritées de l'interface étaient internal, cela voudrait dire que le contrat ne serait respecté qu'à moitié, ça n'aurait pas de sens

Et pour le cas de l'héritage d'une classe, c'est plus simple : tu dois utiliser le même modifier (logique, c'est toujours la même histoire de contrat)
 

internal interface IA
    {
        string Print(string chaine);
    }
 
    internal class A : IA
    {
        public virtual string Print(string chaine)
        {
            return string.Format("¤{0}¤", chaine);
        }
    }
 
    internal class B : A
    {
        internal override string Print(string chaine) // Marche pas
        {
            return string.Format("@{0}@", chaine);
        }
    }

Si le contrat est "internal" je ne voit pas pourquoi l'implémentation est publique...
Si une personne lit mon code est tombe sur une méthodes publiques il va tout de suite penser qu'elle peut être appelée depuis l'extérieur de l'assembly alors que ce n'est pas du tout le cas.
 

Ca veut dire quoi ?
"public" signifie une visibilité totale, également en dehors de l'assembly.
 

Non il serait respecté : visibilité de l'implémentation correspond bien à la visibilité du contrat...

Le contrat n'est pas internal.
C'est sa portée qui est internal.
A ton avis, pourquoi tu ne peux pas mettre d'access modifier aux méthodes d'une interface ? Tout simplement parcequ'elles sont obligatoirement publiques.
 
Et une règle de base de l'héritage, c'est que les méthodes héritées doivent avoir une accessibilité au moins aussi importante que celle de la classe de base... Sinon il se passe quoi si tu utilises une référence de la class de base pour gérer une instance de l'objet dérivé, et que tu appelles une méthode visible dans la classe de base ?
 

Les access modifier sont hérités. public ça signifie juste "aucune restriction par rapport au niveau supérieur. Dans tous les cas, c'est le modifier te ton père qui prime, et ensuite tu regardes si le fils est plus restrictif.
 

Je vois ce que tu veux dire. Mais c'est surtout le modifier d'une interface qui ne devrait jamais pouvoir être autrechose que public (sinon l'interface perd de toute façon tout son intérêt, un contrat c'est fait pour être consultable, pas pour être rangé dans un coffre blindé).
 
Ceci dit, si tu hérites d'une classe qui défini déjà une méthode internal, tu peux tout à fait la rendre internal dans la classe héritée.
 

internal class A
    {
        internal virtual string Print(string chaine)
        {
            return string.Format("¤{0}¤", chaine);
        }
    }
 
    internal class B : A
    {
        internal override string Print(string chaine)
        {
            return string.Format("@{0}@", chaine);
        }
    }

 
Non pas du tout, il a beaucoup de cas ou des interfaces sont très pratiques à l'intérieur d'un assembly. Cela serait trop limitatif de restreindre l'utilisation d'interfaces uniquement entre deux assembly.

Dans ce cas, si ton interface est internal, l'exemple de Taz dans l'autre topic n'est plus applicable, donc t'as plus de problème
 
En tout cas moi je vois pas de problème (si ce n'est que t'as deux topics sur le même sujet et que je sais plus où j'en suis dans mes explications)

J'ai corrigé mon post initial.