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.
Une explication très claire sur la suppression de fichiers dans git
Tout est dans le titre
Un coup de gueule justifié
En résumé de l'article :
- Les états globaux mutables doivent être évités à tout prix.
- On peut réduire le scope d'un état mutable - c'est le but - en passant cet état en tant qu'argument d'une fonction, en utilisant l'injection de dépendances ou des objets de contexte (similaires aux Value Objects).
- Les variables globales ne sont que le sommet de l'iceberg : le plus important est de respecter le principe d'encapsulation, et il y a plusieurs manières de ne pas le faire... Les états globaux mutables ne sont qu'un exemple extrême.
- Les états globaux immutables sont moins pires, mais il est préférable malgré tout de les éviter.
Les 2 commandes à connaître :
git restore --staged monfichier-> si vous avez ajouté monfichier au stage, cela permet de l'enlever de cette étapegit restore monfichier-> si monfichier n'était pas encore suivi ("stage"), cela annule les modifications
Une courte introduction à Babel
Tout est dans le titre
Un article très complet sur l'authentification - l'analogie avec la banque est amusante 😀
Une critique argumentée du principe ouvert/fermé...
L'auteur présente différents points de vue pour définir ce qu'est un système "legacy".
Tout est dans le titre
Un petit souci lors de la mise à jour d'une Debian sid : un changement de font non désiré... L'auteur montre comment il l'a résolu
Tout est dans le titre
Présentation de ce design pattern, et surtout des cas d'utilisation pertinents
Doctrine est souvent le premier choix lorsqu'on commence à utiliser Symfony Messenger... mais ce n'est pas le meilleur choix lorsque les messages en attente sont très nombreux. L'auteur montre comment migrer ceux en attente vers le nouveau gestionnaire de queue (RabbitMQ ou autre)
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre