Abstractions (Types et interfaces abstraits)
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. à partir des Instructions de conception d’une infrastructure : conventions, idiomes et modèles des bibliothèques réutilisables .NET, 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.
Une abstraction est un type qui décrit un contrat, mais qui ne fournit pas une implémentation complète du contrat. Les abstractions sont généralement implémentées en tant que classes ou interfaces abstraites, et elles sont fournies avec un ensemble bien défini de documentation de référence décrivant la sémantique requise des types implémentant le contrat. Certaines des abstractions les plus importantes du .NET Framework incluent Stream, IEnumerable<T>et Object.
Vous pouvez étendre des frameworks en implémentant un type concret qui prend en charge le contrat d’une abstraction et en utilisant ce type concret avec des API de framework consommant (agissant sur) l’abstraction.
Une abstraction significative et utile capable de résister au test du temps est très difficile à concevoir. La principale difficulté est d’obtenir le bon ensemble de membres, pas plus et pas moins. Si une abstraction a trop de membres, il devient difficile ou même impossible d’implémenter. S’il a trop peu de membres pour la fonctionnalité promise, il devient inutile dans de nombreux scénarios intéressants.
Trop d’abstractions dans une infrastructure affectent également négativement l’utilisation de l’infrastructure. Il est souvent difficile de comprendre une abstraction sans comprendre comment elle s’intègre dans l’image plus large des implémentations concrètes et des API qui fonctionnent sur l’abstraction. En outre, les noms des abstractions et de leurs membres sont nécessairement abstraits, ce qui les rend souvent cryptiques et inapprochables sans d’abord comprendre le contexte plus large de leur utilisation.
Toutefois, les abstractions fournissent une extensibilité extrêmement puissante à laquelle les autres mécanismes d’extensibilité ne peuvent souvent pas correspondre. Elles sont au cœur de nombreux modèles architecturaux, tels que les plug-ins, l’inversion de contrôle (IoC), les pipelines, etc. Elles sont également extrêmement importantes pour la testabilité des frameworks. De bonnes abstractions permettent d’extraire les dépendances lourdes à des fins de test unitaire. En résumé, les abstractions sont responsables de la richesse recherchée des infrastructures orientées objets modernes.
❌ Ne fournissez pas d’abstractions, sauf si elles sont testées en développant plusieurs implémentations concrètes et API consommant les abstractions.
✔️ CHOISISSEZ soigneusement entre une classe abstraite et une interface lors de la conception d’une abstraction.
✔️ ENVISAGEZ de fournir des tests de référence pour des implémentations concrètes d’abstractions. Ces tests doivent permettre aux utilisateurs de vérifier si leurs implémentations mettent correctement en œuvre le contrat.
Portions © 2005, 2009 Microsoft Corporation. Tous droits réservés.
Réimprimé avec l’autorisation de Pearson Education, Inc. et extrait de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la série sur le développement Microsoft Windows.