Plusieurs objets écrivant des données : comment éviter cela
Vous connaissez ces moments où vous travaillez sur un programme, et il y a des endroits dans votre code qui, selon les exigences ou un bogue qui se manifeste d’une manière ou d’une autre, sont directement liés au fait que plusieurs objets écrivent des données au même magasin de données ? Ce n’est pas une bonne chose.
C’est une façon terrible de commencer un message. Laissez-moi réessayer.
Plusieurs objets écrivant des données
Supposons que vous travaillez sur un programme et que l’une des choses que fait le code est de mettre à jour un compteur quelque part dans la base de données pour suivre le nombre de modifications qui se sont produites sur une courte période de temps.
Le problème : vous avez plusieurs endroits dans le code qui mettent à jour ce compteur.
Plusieurs objets écrivant des données (au cas où mon écriture serait aussi illisible qu’elle le paraît).
Je ne pense pas que beaucoup d’entre nous aient décidé d’écrire du code comme celui-ci, mais cela arrive, et quand cela arrive, cela finit par avoir tous ces effets secondaires qui engendrent toutes sortes de comportements funky. (Je ne connais pas le terme académique officiel pour cela – et je ne veux pas dire DRY – mais je suis d’accord avec le "comportement génial" pour ce post.)
Nous savons intuitivement que nous devrions avoir un endroit unique où tout cela se passe, des facteurs externes – qu’il s’agisse d’une dérive de la portée, d’un malentendu de notre part pour comprendre les exigences, ou quoi que ce soit – engendrent un codage médiocre.
Nous avons donc toutes ces entités dans notre système, chacune parlant à un seul point de notre base de données (ou à tout autre magasin de données de votre choix), mais aucune d’entre elles ne sait que d’autres lui parlent.
Configurer les limites
Nous pouvons essayer de lutter contre cela avec des conditionnels et autres, mais nous ne faisons qu’empirer les choses. Alors qu’est-ce qu’on est censé faire ?
Je sais que, comme pour beaucoup de choses en programmation, il existe différentes façons de résoudre ce problème, mais peut-être que l’une des premières étapes de la refactorisation consiste à avoir une classe responsable de la publication des mises à jour du magasin de données.
De cette façon, nous pouvons passer de l’illustration ci-dessus à quelque chose comme ceci :
Plusieurs objets écrivant des données : envoyez-les à une sorte de médiateur.
C’est-à-dire que toutes les entités sont en communauté avec cet objet et cet objet – et seul cet objet peut lire et écrire des données dans la base de données.
Il existe quelques modèles de conception qui pourraient répondre à ce problème particulier, mais cela sort du cadre de cet article. Au lieu de cela, le point que j’essaie de faire valoir est que si vous vous trouvez face à un problème de :
- Les entités écrivent des données dans le magasin de données,
- Plusieurs entités le font,
- Et cela engendre des conséquences involontaires,
Essayez ensuite de créer une classe ou un ensemble de classe strictement responsable de la lecture et de l’écriture des données. Laissez seulement les informations passer à travers ces classes plutôt que d’avoir plusieurs classes qui manipulent les données.
Cela facilite le test, le débogage et finalement la lecture.