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

Question

Je suis un développeur C# et .NET assez récent. J'ai récemment créé un snapin MMC à l'aide de C# et j'ai été ravi de la facilité avec laquelle je l'ai fait, surtout après avoir entendu beaucoup d'histoires d'horreur de la part d'autres développeurs de mon organisation sur la difficulté de le faire en C++.

J'ai parcouru l'ensemble du projet à un moment donné et j'ai transformé chaque instance du mot clé "public" en "interne", sauf si le runtime l'exige pour exécuter le snapin. Quel est votre sentiment à ce sujet ? Faut-il généralement rendre les classes et les méthodes publiques ou internes ?

Answer 1

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

À cette fin, ne me donnez que la fonctionnalité que la classe doit exposer pour fonctionner.

Pensez à un ascenseur. Pour le faire monter à 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 devriez faire : donner à vos classes le moins de visibilité possible. Si vous voulez vraiment aller jusqu'au bout de votre démarche, vous pouvez faire en sorte que tout internal (tout au plus) et utiliser le InternalsVisibleTo attribut afin que vous puissiez séparer votre fonctionnalité sans l'exposer au monde extérieur inconnu.

La seule raison de rendre les choses publiques est que vous empaquetez votre projet dans plusieurs DLLs et/ou EXEs et (pour une raison ou une autre) vous ne voulez pas utiliser la fonction InternalsVisibleTo ou vous créez une bibliothèque destinée à être utilisée par des tiers. Mais même dans une bibliothèque destinée à être utilisée par des tiers, vous devez essayer de réduire la "surface" autant que possible ; plus vous avez de classes disponibles, plus votre bibliothèque sera confuse.

En C#, un bon moyen de s'assurer que vous utilisez la visibilité minimale possible est de ne pas utiliser les modificateurs de visibilité jusqu'à ce que vous en ayez besoin. En C#, la visibilité par défaut est la plus faible possible : internal pour les classes, et private pour les membres des classes 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 la diminuer peut poser des problèmes. C'est particulièrement vrai si vous construisez un framework pour d'autres.

Vous devez cependant veiller à ne pas cacher des fonctionnalités utiles à vos utilisateurs. Il existe de nombreuses méthodes utiles dans la BCL de .NET qui ne peuvent ê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 à moins que je veuille explicitement que mon client les consomme, et que je sois prêt à les soutenir.

Au lieu de marquer une classe comme internal je laisse l'accessibilité en blanc. De cette façon, public se distingue à l'œil comme quelque chose de notable. (L'exception, bien sûr, est constituée par les classes imbriquées, qui doivent être marquées si elles doivent être visibles même dans la même assemblée).

Answer 5

Vous devriez avoir tendance à exposer le moins possible aux autres classes, et réfléchir soigneusement à ce que vous exposez et pourquoi.