Tout est dans le titre

L'auteur explique pourquoi il est intéressant, selon lui, de construire des abstractions au dessus des primitives de Kubernetes

Une abstraction a 3 caractéristiques :

• Elle masque les informations inutiles.
• Elle généralise un concept.
• Elle est un point de vue de la réalité (ex: chaque type de carte traite d'un aspect de la géographie, carte routière, carte topographique, carte des monuments, etc.)

On n'oubliera pas qu'une abstraction n'est pas l'objet qu'elle représente !

Comme la programmation concerne les données et le contrôle de leur flux, il y a deux types d'abstractions : les abstractions de données, et les abstractions du contrôle de flux.

Les abstractions de données servent à :

• simplifier en masquant la gestion de la mémoire et les mécanismes de comportement (ex: ne pas faire d'addition sur des chaînes de caractère)
• fournir des comportements génériques réutilisables
• donner aux développeurs le pouvoir de créer de nouvelles abstractions via les "ADT" (Abstract Data Type)

Les abstractions de contrôle sont essentiellement les fonctions car :

• Le nom de la fonction simplifie et masque ses mécanismes internes.
• Une fonction généralise un comportement, qui peut être réutilisé partout.
• Vous devez être conscients que le nom de la fonction peut ne pas correspondre exactement à la réalité (problème du nommage)

En POO, une classe est une abstraction réunissant structure de données et comportement. Il existe aussi les classes abstraites qui permettent de généraliser certains comportements que l'on souhaite masquer. Enfin les interfaces sont aussi des abstractions, même si leur intérêt principal est plutôt la possibilité de changer d'implémentation concrète.

L'avantage principal des abstractions est la simplification en masquant les détails non pertinents. Il y a toutefois des inconvénients à ne pas négliger :

• problème du nommage
• sursimplification -> manque de contrôle par l'utilisateur (interface trop simple), perte de détails (tous les détails ne sont pas à masquer)

Pour pallier ces problèmes, il faut donc rester le plus proche possible du "métier" et ne pas utiliser d'abstraction de prime abord.

Les abstractions masquent les détails inutiles... mais ceux ci peuvent faire surface malgré tout ("fuite") L'endroit où se situe la fuite fera toute la différence dans la résolution du problème : votre code, le code d'un collègue, le code d'une librairie externe, le langage, le matériel !

Ensuite, l'auteur illustre par un exemple le danger de créer une abstraction trop tôt : il avait pensé à plusieurs cas possibles... mais pas suffisamment. Résultat : sa classe a fini par exploser les compteurs de complexité cyclomatique à coup de "if". Il vaut mieux dupliquer du code tant que l'on n'a pas une connaissance raisonnable des abstractions sous jacentes.

L'auteur parle aussi de la confusion entre abstraction et indirection. Une indirection permet de remplacer une partie de l'implémentation par autre chose (ex: les interfaces)

Certaines abstractions créent des indirections (classe abstraite, interfaces)
Créer une indirection ne signifie pas que vous créez une abstraction.
Les indirections facilitent le changement... mais au prix d'une lisibilité moindre.

Tout est dans le titre

Tout est dans le titre