Chapitre 10. Programmation orientée objet

Nous avons évoqué plus haut qu’un des intérêts des objets étaient de pouvoir les utiliser sans se préoccuper de comment ils fonctionnent en interne, de même que vous n’avez pas envie à chaque fois que vous insérez un caractère dans une liste de vérifier s’il n’y a pas d’effets de bord.
De plus, si nous revenons par exemple au code de formulaire, nous voyons qu’il est très fragile. Si un programme passe au constructeur un argument d’un type inapproprié (une suite de lettres pour l’année de naissance par exemple), ce qui n’est nullement interdit, le programme va s’arrêter en renvoyant une exception. Nous pourrions contrôler cela facilement en modifiant le constructeur :
On commence par transformer tous les arguments en autant de chaînes de caractères, de façon à ne pas avoir de comportement différent selon que le constructeur reçoit ’2000’ ou 2000. Puis on vérifie que l’année de naissance ne compte bien que des chiffres, si oui on force la conversion en entier, et sinon on donne une valeur arbitraire.
Ainsi, le comportement du constructeur garantit qu’il n’y aura pas de problème de type. Cependant, en l’état, rien n’interdit au programme de modifier la valeur de l’attribut naissance sans passer par le constructeur – et donc sans garde-fou.
Le problème prévisible survient : le programme force la valeur de naissance à ’yolo’, sans que le constructeur soit consulté et donc qu’un test de type soit effectué, ce qui immanquablement mène à une erreur. L’idée générale de l’encapsulation est d’éviter les effets de bord et les modifications non contrôlées en restreignant les accès en lecture et surtout en écriture des différents attributs à certains canaux…