Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
Un type imbriqué est un type défini dans l’étendue d’un autre type, appelé type englobant. Un type imbriqué a accès à tous les membres de son type englobant. Par exemple, il a accès aux champs privés définis dans le type englobant et aux champs protégés définis dans tous les ascendants du type englobant.
En général, les types imbriqués doivent être utilisés avec parcimonie. et ce, pour plusieurs raisons. Certains développeurs ne connaissent pas pleinement le concept. Ces développeurs peuvent, par exemple, rencontrer des problèmes avec la syntaxe de déclaration de variables de types imbriqués. Les types imbriqués sont également très étroitement couplés à leurs types englobants et, par conséquent, ne sont pas adaptés pour être des types à usage général.
Les types imbriqués sont mieux adaptés à la modélisation des détails d’implémentation de leurs types englobants. L’utilisateur final doit rarement avoir à déclarer des variables d’un type imbriqué et presque jamais à instancier explicitement des types imbriqués. Par exemple, l’énumérateur d’une collection peut être un type imbriqué de cette collection. Les énumérateurs sont généralement instanciés par leur type englobant et, étant donné que de nombreuses langues prennent en charge l’instruction foreach, les variables d’énumérateur doivent rarement être déclarées par l’utilisateur final.
✔️ Utilisez des types imbriqués lorsque la relation entre le type imbriqué et son type externe est telle que la sémantique d’accessibilité des membres est souhaitable.
❌ N’utilisez PAS les types imbriqués publics comme construction de regroupement logique ; utilisez des espaces de noms pour cela.
❌ ÉVITEZ les types imbriqués exposés publiquement. La seule exception à ceci est que si les variables du type imbriqué doivent être déclarées uniquement dans des scénarios rares tels que la sous-classe ou d’autres scénarios de personnalisation avancés.
❌ N’utilisez PAS les types imbriqués si le type est susceptible d’être référencé en dehors du type conteneur.
Par exemple, une énumération passée à une méthode définie sur une classe ne doit pas être définie comme un type imbriqué dans la classe.
❌ N’utilisez PAS les types imbriqués s’ils doivent être instanciés par le code client. Si un type dispose d’un constructeur public, il ne doit probablement pas être imbriqué.
Si un type peut être instancié, qui semble indiquer que le type a un emplacement dans l’infrastructure seul (vous pouvez le créer, l’utiliser et le détruire sans jamais utiliser le type externe), et ne doit donc pas être imbriqué. Les types internes ne doivent pas être largement réutilisés en dehors du type externe sans aucune relation avec le type externe.
❌ NE DÉFINISSEZ PAS un type imbriqué en tant que membre d’une interface. De nombreuses langues ne prennent pas en charge une telle construction.
Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.
Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.