Pourquoi pas ma classe publique d'étendre une classe interne?
Je n'ai vraiment pas l'obtenir.
Si la classe de base abstraite et uniquement destiné à être utilisé pour fournir des fonctionnalités communes pour public sous-classes définies dans l'assemblée, pourquoi ne devrait-elle pas être déclaré en interne?
Je ne veux pas la classe abstraite pour être visible de code en dehors de l'assemblée. Je ne veux pas de code externe à savoir sur le sujet.
Vous devez vous connecter pour publier un commentaire.
En héritant d'une classe, vous exposer les fonctionnalités de la classe de base par l'intermédiaire de votre enfant.
Depuis l'enfant de la classe a le plus de visibilité que son parent, vous serait d'exposer les membres qui autrement seraient protégées.
Vous ne pouvez pas violer le niveau de protection de la classe parent par la mise en œuvre d'un enfant avec une plus grande visibilité.
Si la classe de base est vraiment destinée à être utilisée par les enfants des classes, alors vous avez besoin de faire le parent public.
L'autre option est de garder votre "parent" interne, de le rendre abstrait, et l'utiliser pour composer votre enfant des classes, et l'utilisation d'une Interface à la force des classes pour implémenter la fonctionnalité:
Mise à JOUR: Cette question a été le sujet de mon blog le 13 novembre 2012. Voir pour plus de pensées sur cette question. Merci pour la grande question!
Vous avez raison; il n'a pas à être de cette façon. D'autres langages à objets permettent de "privé de l'héritage", selon lequel le fait que D hérite de B ne peut être mis à profit par le code qui a la capacité de voir B.
C'était une décision de conception de l'original C# concepteurs. Malheureusement, je suis loin de mon bureau en ce moment - je vais prendre une couple de jours de congé pour le long week - end donc je n'ai pas la langue des design notes à partir de 1999 en face de moi. Si je pense à elle quand je rentre je vais les parcourir et de voir s'il existe une justification de cette décision.
Mon opinion personnelle est que l'héritage doit être utilisé pour représenter "est une sorte de" relations", c'est, l'héritage doit représenter la sémantique du domaine modélisé dans la langue. J'essaie d'éviter les situations où l'héritage est utilisé comme un code de mécanisme de partage des. Comme d'autres l'ont mentionné, il est probablement préférable de préférer la composition à l'héritage si ce que vous voulez représenter est "cette classe d'actions mécanismes de mise en œuvre avec d'autres classes".
Tuple<>
implémenteITuple
, qui est interne.Je pense que la chose la plus proche que vous pouvez faire est d'empêcher les autres assemblées de la création de la classe abstraite en la rendant constructeur de l'intérieur, pour citer MSDN:
Ensuite, vous pouvez essayer d'ajouter un EditorBrowsableAttribute à la classe de l'essayer et de le cacher de Intellisense (quoique, j'ai eu des résultats mitigés de l'utiliser pour être honnête) ou mettre de la classe de base dans un espace de noms imbriqué, comme
MyLibrary.Internals
les séparer du reste de vos classes.Je pense que vous êtes de mélange préoccupations ici, et C# est à blâmer, en fait (et Java avant).
Héritage devrait servir comme un mécanisme de catégorisation, alors qu'il est souvent utilisé pour la réutilisation du code.
Pour la réutilisation du code, il a toujours été connu que la composition beats héritage. Le problème avec le C#, c'est qu'il nous donne une façon simple d'hériter:
Mais dans le but de composer, nous avons besoin de le faire par nous-mêmes:
Ce qu'il manque, c'est une construction comme un trait (pdf), qui apportera de la composition de la même facilité d'utilisation niveau de l'héritage.
Il y a des recherches sur les traits en C# (pdf), et il devrait ressembler à quelque chose comme ceci:
Bien que j'aimerais voir un autre modèle (celle de Perl 6 rôles).
Mise à JOUR:
Comme une note de côté, l'Oxygene de la langue a une fonctionnalité qui vous permet de déléguer tous les membres d'une interface à un membre de la propriété qui implémente cette interface:
Ici, tous les membres d'interface de
IReusable
seront exposés à traversMyClass
et ils vont tous délégué à laReused
de la propriété. Il y a quelques problèmes avec cette approche, bien qu'.UNE AUTRE MISE À JOUR:
J'ai commencé à mettre en œuvre ce dispositif de composition concept en C#: jetez un oeil à NRoles.
Je pense que ce serait violer le Principe De Substitution De Liskov.
Dans des cas comme cela, j'ai utilisé les classes internes et préfèrent la composition au cours de l'héritage. Est-il quelque chose au sujet de votre conception qui interdit contenant toutes les fonctionnalités de votre classe interne, et ensuite votre public classes contiennent une instance de cette classe interne?