Devrais-je utiliser la visibilité interne ou publique par défaut?

Question

Je suis un tout nouveau développeur C # et .Net. J'ai récemment créé un composant logiciel enfichable MMC utilisant C # et je suis ravi de la facilité avec laquelle il est capable de le faire, en particulier après avoir entendu de nombreux récits d'horreur racontés par d'autres développeurs de mon entreprise sur la difficulté de le faire en C ++.

J’ai à peu près parcouru l’ensemble du projet à un moment donné et j’ai rendu chaque instance du "public" mot-clé to "internal", sauf si le runtime l'exige pour exécuter le composant logiciel enfichable. Quel est votre sentiment à ce sujet, devriez-vous généralement rendre les cours et les méthodes publics ou internes?

Answer 1

Je crois aux boîtes noires lorsque cela est possible. En tant que programmeur, je veux une boîte noire bien définie que je puisse facilement insérer dans mes systèmes et la faire fonctionner. Je lui donne des valeurs, appelle les méthodes appropriées, puis récupère mes résultats.

À cette fin, donnez-moi uniquement les fonctionnalités que la classe doit exposer pour fonctionner.

Considérons un ascenseur. Pour le faire aller à un étage, j'appuie sur un bouton. C’est l’interface publique de la boîte noire qui active toutes les fonctions nécessaires pour amener l’ascenseur à l’étage souhaité.

Answer 2

Ce que vous avez fait est exactement ce que vous devez faire. donnez à vos cours la visibilité la plus minimale possible. Heck, si vous voulez vraiment tout faire, vous pouvez faire tout internal (au plus) et utiliser le attribut InternalsVisibleTo , afin que vous puissiez séparer vos fonctionnalités sans les exposer vers le monde extérieur inconnu.

La seule raison pour rendre public les choses, c'est que vous empaquetez votre projet dans plusieurs DLL et / ou EXE et que (peu importe la raison) vous ne souhaitez pas utiliser InternalsVisibleTo , ou vous ' recréer une bibliothèque pour une utilisation par des tiers. Mais même dans une bibliothèque destinée à être utilisée par des tiers, vous devriez essayer de réduire la "surface". la mesure du possible; plus vous avez de classes disponibles, plus votre bibliothèque sera déroutante.

En C #, un bon moyen de vous assurer que vous utilisez la visibilité minimale possible est de laisser les modificateurs de visibilité jusqu'à ce que vous en ayez besoin. Par défaut, tout en C # présente la visibilité la plus faible possible: interne pour les classes et privé pour les membres et les classes internes.

Answer 3

Je pense que vous devriez privilégier les classes et les membres internes. Vous pouvez toujours augmenter la visibilité d'un élément, mais sa diminution peut entraîner des problèmes. Cela est particulièrement vrai si vous construisez un cadre pour les autres.

Vous devez toutefois veiller à ne pas masquer les fonctionnalités utiles de vos utilisateurs. Il existe de nombreuses méthodes utiles dans le BCL .NET qui ne peuvent pas être utilisées sans recourir à la réflexion. Cependant, en cachant ces méthodes, la surface de ce qui doit être testé et maintenu est réduite.

Answer 4

Je préfère éviter de marquer les classes comme public sauf si je souhaite explicitement que mon client les consomme, et je suis prêt à les prendre en charge.

Au lieu de marquer une classe comme interne , je laisse l'accessibilité en blanc. De cette façon, public se démarque comme un élément notable. (L’exception, bien sûr, concerne les classes imbriquées, qui doivent être marquées si elles doivent être visibles même dans le même assemblage.)

Answer 5

La plupart des classes doivent être internes , mais la plupart des membres non privés doivent être public .

La question que vous devriez poser à propos d'un membre est "si la classe a été rendue publique , est-ce que je voudrais que le membre soit exposé?". La réponse est généralement "oui (donc public )". car les classes sans membres accessibles ne sont pas d'une grande utilité! Les membres internes ont un rôle; ils constituent un «accès par la porte arrière» destiné uniquement aux parents proches qui vivent dans la même assemblée.

Même si votre classe reste interne, il est agréable de voir quels sont les membres de la porte d'entrée et ceux qui sont de la porte arrière. Et si vous le changez en public, vous ne devrez pas revenir en arrière et réfléchir à ce qui est lequel.

Answer 6

Vous devriez avoir tendance à exposer le moins possible à d'autres classes et à bien réfléchir à ce que vous exposez et pourquoi.

Answer 7

Y a-t-il une raison pour laquelle vous devez utiliser interne au lieu de privé? Vous vous rendez compte qu'Internal a une portée de niveau assembleur. En d'autres termes, les classes / membres internes sont accessibles à toutes les classes d'un assemblage multi-classes.

Comme d'autres réponses l'ont déjà indiqué, privilégiez le plus haut niveau possible d'encapsulation (c'est-à-dire privé) à moins que vous n'ayez réellement besoin de internal / protected / public.

Answer 8

J'ai trouvé un problème d'utilisation des classes internes autant que possible. Vous ne pouvez pas avoir des méthodes, propriétés, champs, etc. de ce type (ou type de paramètre ou type de retour) plus visibles qu'interne. Cela conduit à avoir des constructeurs internes, ainsi que des propriétés. Cela ne devrait pas être un problème, mais en fait, l'utilisation de Visual Studio et du concepteur xaml pose des problèmes. Des erreurs fausses positives sont détectées par le concepteur en raison du fait que les méthodes ne sont pas publiques, les propriétés de contrôle de l'utilisateur ne semblent pas visibles pour le concepteur. Je ne sais pas si d'autres sont déjà tombés dans de telles situations ...

Answer 9

Vous devriez essayer de les rendre aussi visibles que possible, mais comme l’a dit Mike ci-dessus, cela pose des problèmes avec UserControls et l’utilisation de VS Designer avec ces contrôles de formulaires ou d’autres UserControls.

Donc, en règle générale, conservez toutes les classes et contrôles utilisateur que vous ne souhaitez pas ajouter à l'aide de Designer uniquement si visibles qu'ils doivent l'être. Même si vous créez un UserControl que vous souhaitez utiliser dans le concepteur (même si c'est dans le même assemblage), vous devez vous assurer que la classe UserControl, son constructeur par défaut et toutes les propriétés et événements sont rendus publics pour le concepteur. travailler avec elle.

J'ai récemment eu un problème où le concepteur continuait à supprimer la ligne this.myControl = new de MyControl () de la méthode InitializeComponent (), car UserControl MyControl était marqué comme interne avec son constructeur.

C’est vraiment un bogue, je pense, parce que même s’ils sont marqués comme internes, ils apparaissent toujours dans la boîte à outils à ajouter dans le concepteur, soit Microsoft doit uniquement afficher les contrôles publics avec des constructeurs publics, ou ils doivent le faire fonctionner avec les contrôles internes aussi.

Answer 10

Cela dépend de votre contrôle sur le code qui le consomme. Dans mon développement Java, je rend toutes mes données publiques par défaut car les accesseurs sont gênants. Cependant, j'ai aussi le luxe de pouvoir changer n'importe quoi dans mon code quand je le veux. Dans le passé, lorsque je devais divulguer du code aux consommateurs, je utilisais toujours des variables privées et des accesseurs (getters).

Answer 11

Ne choisissez pas un " défaut " Choisissez ce qui correspond le mieux aux besoins de visibilité de cette classe. Lorsque vous choisissez une nouvelle classe dans Visual Studio, le modèle est créé en tant que:

class Class1
{
}

Qui est privé (car aucune étendue n'est spécifiée). Il vous appartient de spécifier la portée de la classe (ou de la laisser privée). Il devrait y avoir une raison pour exposer la classe.

Answer 12

J'aime exposer les choses le moins possible. Privé, protégé, interne, public: donnez aux classes, variables, propriétés et fonctions le minimum de visibilité dont ils ont besoin pour que tout fonctionne toujours.

Je ferai passer la visibilité de quelque chose en haut de cette chaîne vers le public uniquement lorsqu'il y a une bonne raison de le faire.

Answer 13

Je suis complètement en désaccord avec les réponses jusqu'à présent. Je pense qu'internal est une idée horrible, empêchant un autre assemblage d'hériter de vos types, ou même d'utiliser vos types internes si le besoin d'une solution de contournement se présentait.

Aujourd'hui, je devais utiliser la réflexion pour accéder aux éléments internes d'un System.Data.DataTable (je dois construire un éclair rapide, sans toutes ses vérifications), et je devais utiliser la réflexion, car un seul type était disponible pour moi; ils ont tous été marqués comme internes.

Answer 14

par défaut, la classe est créée en interne en c #:  moyen interne: l'accès est limité à l'ensemble en cours.

voir http://msdn.microsoft.com/en-us/library/0b0thckt.aspx

Bon article la portée par défaut est interne: http: //www.c-sharpcorner. com / UploadFile / 84c85b / default-scope-of-aC-Sharp-class /