Lorsque vous définissez une classe comme interne, définissez-vous généralement les champs publics comme internes?

Question

Lorsque vous définissez une classe comme interne, définissez-vous généralement les champs publics comme internes? Ou les laissez-vous en public? J'ai un ensemble de classes avec des méthodes publiques/privées que j'ai décidé de définir comme internes. Maintenant, devrais-je changer le modificateur de la classe en interne et laisser le reste des méthodes/propriétés telles qu'elles sont (public/private) ou les changer en (internal/private)?

Je ne vois pas l'intérêt de le changer en interne, et si par la suite je veux les remettre au public, il faudra beaucoup de travail pour les remettre en public.

D'autres réflexions à ce sujet?

Answer 1

Je ne vois aucune raison de ne pas les laisser en public, car votre classe ne sera pas visible pour les assemblages extérieurs de toute façon. Le seul cas où je pense que cela pourrait avoir de l'importance est d'utiliser la réflexion sur cette classe.

Answer 2

Vous ne devriez pas changer les membres privés en interne car cela les rendrait plus accessibles. Il n'est pas nécessaire de changer les membres publics en internes puisque rien en dehors de l'assembly définissant ne pourra jamais obtenir une référence à une classe interne de toute façon.

Answer 3

Si j'ai une classe interne, je laisse les membres de la classe en public (ou protégés/privés bien sûr si c'est ce qu'ils étaient). Je trouve souvent que j'ai des cours que j'espère pouvoir garder internes et que je finis par devoir exposer à la fin et que je mets tous les membres appropriés au public, c'est ennuyeux.

Answer 4

Je pense que vous devriez donner à tous les membres la même visibilité que si le Type était lui-même public. En d'autres termes, les membres qui font partie de l'API publique doivent être publics, et les membres qui sont des aides spécifiques qui ne doivent être visibles que pour les classes "friend" doivent être internes. Cela signifie que la visibilité des membres ne sera pas modifiée si vous décidez de rendre le Type public. Plus important encore, il documente également votre intention - toute personne lisant votre code sera en mesure d'identifier quels (le cas échéant) les membres sont destinés à être interne.

Answer 5

Nous utilisons un mot-clé interne pour les membres dans les classes internes, de sorte que l'intention est claire. Cependant, il échoue si l'on implémente implicitement des interfaces internes, où les membres doivent être définis comme publics. Nous ne savons pas pourquoi et voyons cela comme une erreur accidentelle dans la spécification de la langue avec laquelle nous devons vivre.

Answer 6

Fouillez-vous un peu dans Reflector et vous verrez que le BCL lui-même est extrêmement incohérent. Vous verrez beaucoup de classes internes avec des membres public et beaucoup d'autres avec internal membres. Plusieurs classes même mélanger et assortir les deux sans aucune rime ou raison particulière que je suis capable de discerner.

Il n'y a pas de « bonne » réponse, mais il y a quelques choses que vous devriez considérer chaque fois que vous devez prendre une décision à ce sujet:

• membres internal ne peuvent pas mettre en œuvre implicitement une interface et des implémentations explicites sont toujours privés. Donc, si vous voulez que les membres de l'interface soient accessibles via l'instance class (la méthode Dispose de IDisposable est une instance courante), ils doivent être publics.

• Les visibilités de type peuvent changer. Vous pourriez décider que la classe internal possède des fonctionnalités utiles que vous voulez mettre à la disposition de l'extérieur. Mais si vous faites, alors tous les membres publics deviennent accessibles par tout le monde. Vous devriez décider à l'avance si c'est ce que vous voulez. D'autre part, une autre raison pour laquelle vous pouvez créer une classe internalpublic est si vous décidez que vous avez besoin de la sous-classer et que les classes dérivées doivent être dans un assembly différent. Dans ce cas, certains de vos membres internal devraient probablement être protected internal à la place, sinon les classes dérivées n'auront pas accès aux membres dont ils pourraient avoir besoin.

En fin de compte, ce que tout se résume à est le code d'écriture pour être lu et maintenu par d'autres personnes. Le modificateur internal peut signifier deux choses très différentes à un programmeur de maintenance:

1. Qu'il ne semble pas utile au monde extérieur, mais ne serait pas réellement être nuisibles soit. Un exemple typique serait une classe d'utilité qui a été fouettée en 5 minutes et ne fait pas beaucoup de validation ou de vérification d'erreurs. Dans ce cas, c'est OK pour quelqu'un de le faire public tant qu'ils resserrent un peu le code et/ou documentent comment l'utiliser correctement. Rendre cette hypothèse explicite en faisant les membres public.

2. Il s'agit en fait de non sûr pour consommation extérieure; Dans ce cas, vous voulez vraiment faire les méthodes individuelles internal pour qu'il soit absolument clair que personne d'autre ne devrait utiliser cette classe, jamais.

Choisissez l'option appropriée pour votre scénario.