classe dérivée accessibilité

Question

Pourquoi, en C#, il n'est pas permis aux classes dérivées d'avoir une plus grande accessibilité que leur classe de base.

Par exemple, l'erreur suivante se produira : Inconsistent accessibility : base class 'BaseClass' is less accessible than class 'DerivedClass' (accessibilité incohérente : la classe de base 'BaseClass' est moins accessible que la classe 'DerivedClass')

internal class BaseClass
{
}

public class DerivedClass : BaseClass
{
}

Et pourquoi il est autorisé en Java.

Answer 1

MISE À JOUR : Cette question a été le sujet de mon blog le 13 novembre 2012 . Merci pour cette excellente question !

Pourquoi, en C#, n'est-il pas permis aux classes dérivées d'avoir une plus grande accessibilité que leur classe de base ?

En plus des autres bonnes réponses, considérez ce scénario. Vous et votre collègue Alice travaillez sur des parties différentes du même assemblage. Alice écrit un cours :

public class ComplicatedClass
{
    public void DoDangerousThing() { ... }
}

Vous écrivez ensuite

public class EvenMoreComplicatedClass : ComplicatedClass
{
}

Grandes. Maintenant, Alice obtient un examen de sécurité de Bob, et ils réalisent que (1) aucun client n'a jamais eu besoin d'utiliser ComplicatedClass, et (2) DoDangerousThing expose une faille de sécurité dont un code hostile pourrait tirer parti. Le code interne, bien sûr, ne le fait pas.

Alice modifie donc son code en

internal class ComplicatedClass
{
    public void DoDangerousThing() { ... }
}

Il n'est pas nécessaire de remplacer "public" par "interne" dans la méthode car, bien entendu, "public" signifie "public pour les choses qui peuvent voir cette classe" et, à présent, aucun code externe ne peut voir cette classe.

Que devrait-il arriver à votre code lorsque Alice le recompilera en tenant compte de cette modification ? La compilation devrait échouer . Vous avez supposé que les utilisateurs ont besoin de voir la classe de base, et Alice a apporté une modification qui va à l'encontre de cette supposition. La chose sûre à faire est que le compilateur dise à Alice qu'elle doit venir vous parler afin que vous puissiez résoudre ce problème sans exposer le client à la vulnérabilité de DoDangerousThing.

Pourquoi est-il autorisé en Java ?

Aucune idée, désolé.

Answer 2

De cette façon, il serait trivial d'utiliser une classe marquée comme interne ou privée comme si elle était publique, en faisant simplement une surcharge vide, comme vous l'avez fait dans votre exemple. Cela irait à l'encontre de l'objectif de marquer les classes autrement que comme publiques.

Answer 3

internal n'est pas la même chose que package private en Java. L'utilisateur de DerivedClass mayo n'a pas ou n'a pas accès à la DLL qui BaseClass est en si DerivedClass ne peut pas en dépendre. La confidentialité des paquets est un concept beaucoup plus vague en Java - mais dans votre exemple, DerivedClass devrait se trouver dans le même paquet que BaseClass il y a donc de fortes chances que l'utilisateur client dispose de ces deux classes, de sorte que Java l'autorise.

Answer 4

Sinon, vous exposeriez les membres de BaseClass plus loin que prévu.

Voici un exemple de problème public const int Age . Cela ne pose pas de problème car il n'est exposé qu'à l'intérieur d'un même assemblage, de sorte que le versionnage est sûr. Si vous utilisez maintenant l'héritage pour rendre la classe publique, vous exposez ce champ const en dehors de l'assembly. Cela peut provoquer des erreurs si la valeur est modifiée.

Souvent, je rends une classe interne afin de ne pas avoir à me préoccuper de la version de son interface publique à l'avenir. Je suis libre de la modifier à tout moment et tant que l'assemblage se compile, tout va bien. Si quelqu'un venait à l'exposer publiquement, je devrais alors respecter cette interface publique pour toujours.