Je pense que vous trouverez peut-être utile de publier un article de mon blog sur les abstractions qui fuient. Voici le fond pertinent:
L'abstraction est un mécanisme permettant de prendre ce qui est commun parmi un ensemble de fragments de programme liés, de supprimer leurs différences et de permettre aux programmeurs de travailler directement avec une construction représentant ce concept abstrait. Cette nouvelle construction (pratiquement) a toujours des paramétrisations : un moyen de personnaliser l’utilisation de la construction pour répondre à vos besoins spécifiques.
Par exemple, une List
classe peut faire abstraction des détails d'une implémentation de liste chaînée - au lieu de penser en termes de manipulation next
et de previous
pointeurs, vous pouvez envisager d'ajouter ou de supprimer des valeurs à une séquence. L'abstraction est un outil essentiel pour créer des caractéristiques utiles, riches et parfois complexes à partir d'un ensemble beaucoup plus petit de concepts plus primitifs.
L'abstraction est liée à l'encapsulation et à la modularité, et ces concepts sont souvent mal compris.
Dans l' List
exemple, l' encapsulation peut être utilisée pour masquer les détails d'implémentation d'une liste liée. dans un langage orienté objet, par exemple, vous pouvez rendre les next
et les previous
pointeurs privés, seule l'implémentation de la liste étant autorisée à accéder à ces champs.
L'encapsulation n'est pas suffisante pour l'abstraction, car cela n'implique pas nécessairement que vous ayez une conception nouvelle ou différente des constructions. Si toute la List
classe ne vous donnait que des méthodes d'accès de style ' getNext
' setNext
', elle encapsulerait à partir des détails de l'implémentation (par exemple, avez-vous nommé le champ' prev
'ou' previous
'? Quel était son type statique?), Mais aurait un très faible degré d'abstraction.
La modularité concerne la dissimulation d'informations : des propriétés stables sont spécifiées dans une interface, et un module implémente cette interface, en conservant tous les détails de la mise en œuvre dans le module. La modularité aide les programmeurs à faire face aux changements, car les autres modules ne dépendent que de l'interface stable.
L'encapsulation facilite la dissimulation d'informations (de sorte que votre code ne dépend pas de détails d'implémentation instables), mais l'encapsulation n'est pas nécessaire pour la modularité. Par exemple, vous pouvez mettre en œuvre une List
structure C, ce qui expose les « next
» et « prev
» pointeurs au monde, mais aussi fournir une interface, contenant initList()
,addToList()
etremoveFromList()
les fonctions. Si les règles de l'interface sont suivies, vous pouvez vous assurer que certaines propriétés seront toujours valables, par exemple en vous assurant que la structure de données est toujours dans un état valide. [Le document classique de Parnas sur la modularité, par exemple, a été écrit avec un exemple en assemblage. L'interface est un contrat et une forme de communication à propos de la conception, elle ne doit pas nécessairement être vérifiée mécaniquement, bien que nous en dépendions aujourd'hui.]
Bien que les termes abstraits, modulaires et encapsulés soient utilisés en tant que descriptions de conception positives, il est important de comprendre que la présence de l'une de ces qualités ne vous donne pas automatiquement une bonne conception:
Si un algorithme n ^ 3 est "joliment encapsulé", il fonctionnera toujours moins bien qu'un algorithme amélioré de n log n.
Si une interface est validée par un système d'exploitation spécifique, aucun des avantages d'une conception modulaire ne sera réalisé lorsque, par exemple, un jeu vidéo doit être transféré de Windows vers l'iPad.
Si l'abstraction créée expose trop de détails non essentiels, elle ne pourra pas créer une nouvelle construction avec ses propres opérations: ce sera simplement un autre nom pour la même chose.