Le mot-clé pour penser à ces choses est l' abstraction .
L'abstraction signifie simplement d'ignorer délibérément les détails d'un système afin que vous puissiez le considérer comme un composant unique et indivisible lors de l'assemblage d'un système plus grand à partir de nombreux sous-systèmes. Il est d'une puissance inimaginable - écrire un programme d'application moderne tout en considérant les détails de l'allocation de mémoire et du déversement des registres et des temps d'exécution des transistors serait possible d'une manière idéalisée, mais il est incomparablement plus facile de ne pasd'y penser et d'utiliser à la place des opérations de haut niveau. Le paradigme informatique moderne repose essentiellement sur plusieurs niveaux d'abstraction: électronique à semi-conducteurs, microprogrammation, instructions machine, langages de programmation de haut niveau, OS et API de programmation Web, cadres et applications programmables par l'utilisateur. Pratiquement personne ne pouvait comprendre l'ensemble du système de nos jours, et il n'y a même pas de voie imaginable par laquelle nous pourrions jamais revenir à cet état de fait.
Le revers de l'abstraction est la perte de puissance. En laissant les décisions sur les détails à des niveaux inférieurs, nous acceptons souvent qu'elles puissent être prises avec une efficacité sous-optimale, car les niveaux inférieurs n'ont pas le `` Big Picture '' et peuvent optimiser leur fonctionnement uniquement par la connaissance locale, et ne sont pas aussi (potentiellement) intelligent en tant qu'être humain. (Habituellement. Par exemple, la compilation de HLL en code machine est de nos jours souvent mieux effectuée par les machines que par l'homme le plus compétent, car l'architecture du processeur est devenue si compliquée.)
La question de la sécurité est intéressante, car les failles et les «fuites» dans l'abstraction peuvent souvent être exploitées pour violer l'intégrité d'un système. Lorsqu'une API postule que vous pouvez appeler les méthodes A, B et C, mais uniquement si la condition X est remplie, il est facile d'oublier la condition et de ne pas être préparé aux retombées qui se produisent lorsque la condition est violée. Par exemple, le débordement de tampon classique exploite le fait que l'écriture dans des cellules de mémoire produit un comportement indéfini sauf si vous avez alloué vous-même ce bloc de mémoire particulier. L'API garantit seulement que quelque chosese produira en conséquence, mais dans la pratique, le résultat est défini par les détails du système au niveau inférieur suivant - que nous avons délibérément oublié! Tant que nous remplissons la condition, cela n'a aucune importance, mais sinon, un attaquant qui comprend intimement les deux niveaux peut généralement diriger le comportement de l'ensemble du système comme souhaité et provoquer de mauvaises choses.
Le cas des bogues d'allocation de mémoire est particulièrement mauvais car il s'est avéré très difficile de gérer la mémoire manuellement sans une seule erreur dans un grand système. Cela pourrait être considéré comme un cas d'abstraction raté: bien qu'il soit possible de faire tout ce dont vous avez besoin avec le Cmalloc
API, c'est tout simplement trop facile à abuser. Certaines parties de la communauté de programmation pensent maintenant que ce n'était pas le bon endroit pour introduire une limite de niveau dans le système, et à la place promouvoir les langues avec la gestion automatique de la mémoire et la collecte des ordures, qui perd un peu de puissance, mais offre une protection contre la corruption de mémoire et un comportement indéfini . En fait, une raison majeure de continuer à utiliser C ++ de nos jours est précisément le fait qu'il vous permet de contrôler exactement quelles ressources sont acquises et libérées quand. De cette façon, le schisme majeur entre les langues gérées et non gérées aujourd'hui peut être vu comme un désaccord sur l'endroit où définir précisément une couche d'abstraction.
La même chose peut être dite pour de nombreux autres paradigmes alternatifs majeurs dans l'informatique - le problème surgit vraiment tout le temps où de grands systèmes doivent être construits, parce que nous sommes tout simplement incapables de concevoir des solutions à partir de zéro pour les exigences complexes courantes aujourd'hui. (Un point de vue commun en IA ces jours -ci est que le cerveau humain en fait fait le travail comme celui - comportement résultant par des boucles de rétroaction, les réseaux massivement interconnectés etc. au lieu de modules séparés et des couches avec de simples interfaces abstraites entre eux, et que c'est pourquoi nous ont si peu réussi à simuler notre propre intelligence.)