Série sur l'abstraction

Tout élément qui cache certains détails d’implémentation/façon de fonctionner afin de n’exposer qu’un concept général plus simple à utiliser et à comprendre.

Ex. une laveuse, un guichet automatique, un volant d’une voiture, etc.

2.1 Si nous avons assez d’informations concernant X, Y et leur contexte qui permettent de déterminer que X et Y offrent vraiment la même capacité et que le client a besoin de cette capacité, alors il pourrait être préférable d’immédiatement créer l’abstraction.

2.2 S’il manque des informations concernant X et Y qui permettent de déterminer avec confiance que X et Y ont les mêmes capacités, alors il est préférable d’attendre d’avoir davantage d’informations avant d’extraire une abstraction, car il est fort possible que des changements surviennent et invalident l'abstraction. Ou si on sait pertinemment que X et Y ont deux contextes différents. Ceci dit, la composition est souvent utilisée pour ne pas avoir de duplication, sans toutefois créer tout de suite une abstraction.

Post intéressant à lire concernant les mauvaises abstractions: The Wrong Abstraction

Il est préférable de privilégier la composition par rapport à l'héritage/abstraction, car les conséquences d'un mauvais héritage/abstraction sont coûteuses. Passer par une étape intermédiaire, c'est-à-dire la composition, permet de ne pas avoir de duplication, en attendant d'avoir davantage d'informations sur le contexte et la capacité des éléments afin d'en extraire une abstraction ou une hiérachie polymorphique.

Caractéristique d’une abstraction qui dévoile des détails qu’elle est supposée abstraire. La loi des leaky abstractions stipule qu’aucune abstraction ne peut parfaitement nous protéger des problèmes. Elle stipule également que pour utiliser l’abstraction “leaky”, il faut que les développeurs connaissent les détails d’implémentation qui se cachent en dessous afin de bien utiliser l’abstraction et comprendre les impacts de son utilisation.

Une abstraction qui s’applique à tous les contextes au final ne s’applique à aucun contexte. Si une abstraction est trop générale, il devient difficile de comprendre dans quel cas l’utiliser et ce qu’elle fait réellement.

Ex. une interface avec une méthode handle ou une interface qui s'appelle Stuff.

L’abstraction sera peu utile puisqu’il faudra effectuer des changements à toutes les fois que les spécificités changeront (vouloir mettre un contrat en fonction du degré d'intimité ce qui entraîne la propagation des changements) alors qu’un des objectifs de poser une abstraction est de se protéger des changements. De plus elle ne pourra probablement pas s'appliquer à plusieurs contextes puisque trop précise.

Une interface peut être spécifique (avoir une capacité spécifique) si elle n'a pas le même cycle de vie que son appelant, c'est-à-dire que l'interface ne change pas à chaque fois que l'implémentation change. De plus, il ne faut pas qu'il y ait des détails d'implémentation (fuite d'abstraction).

Il serait préférable d’utiliser une classe abstraite lorsque les enfants ont des comportements communs qu’il est possible d’extraire et que cette partie sera instrinsèquement commune aux futures implémentations. Alors qu’une interface est préférable si tous les enfants ont des implémentations différentes.

L’abstraction est le fait de cacher certains détails d’implémentation afin d’en simplifier l’utilisation et de se protéger des changements.

L’indirection est le fait d’appeler un élément par un autre élément c’est à dire d’ajouter une couche intermédiaire afin de:

• ajouter une transformation sur un objet
• simplifier la communication entre les deux objets
• ajouter des éléments de sécurité
• etc.

L’abstraction fait appel à l’indirection, mais l’indirection ne fait pas nécessairement référence à l’abstraction.