Worldlex Wiki La séparation commande-requête ( CQS ) est un principe de la programmation impérative . Elle a été conçue par Bertrand Meyer dans le cadre de ses travaux pionniers sur le langage de programmation Eiffel .
Il est stipulé que toute méthode doit être soit une commande exécutant une action, soit une requête renvoyant des données à l'appelant, mais pas les deux. Autrement dit, poser une question ne doit pas modifier la réponse . Plus formellement, les méthodes ne doivent renvoyer une valeur que si elles sont référentiellement transparentes et, par conséquent, sans effets de bord .
Lien avec la conception par contrat
La séparation commandes-requêtes est particulièrement adaptée à la méthodologie de conception par contrat (DbC), où la conception d'un programme est exprimée par des assertions intégrées au code source , décrivant l' état du programme à certains moments critiques. En DbC, les assertions sont considérées comme des annotations de conception – et non comme de la logique du programme – et, de ce fait, leur exécution ne doit pas affecter l'état du programme. La séparation commandes-requêtes (CQS) est avantageuse pour la DbC car toute méthode renvoyant une valeur (toute requête) peut être appelée par n'importe quelle assertion sans risque de modification de l'état du programme.
En théorie, cela établit un niveau de cohérence permettant de raisonner sur l'état d'un programme sans le modifier simultanément. En pratique, le CQS permet de contourner tous les contrôles d'assertion dans un système en fonctionnement afin d'améliorer ses performances sans en modifier involontairement le comportement. Le CQS peut également prévenir l'apparition de certains types de bogues de Heisenberg .
Impact plus large sur l'ingénierie logicielle
Au-delà même du lien avec la conception par contrat, les adeptes du CQS considèrent qu'il a un effet simplificateur sur un programme, rendant ses états (via des requêtes) et ses changements d'état (via des commandes) plus compréhensibles.
Le CQS est parfaitement adapté à la méthodologie orientée objet , mais peut également être appliqué en dehors de ce cadre. Puisque la séparation des effets de bord et des valeurs de retour n'est pas intrinsèquement liée à l'orientation objet, le CQS peut être avantageusement appliqué à tout paradigme de programmation nécessitant une prise en compte des effets de bord.
Séparation des responsabilités des commandes et des requêtes
La séparation des responsabilités de commande et de requête ( CQRS ) généralise le CQS aux services, au niveau des architectures : elle applique le principe du CQS en utilisant des interfaces de requête et de commande distinctes et généralement des modèles de données pour récupérer et modifier les données, respectivement.
Autres modèles architecturaux
- En nous éloignant d'une représentation unique avec laquelle nous interagissons via CRUD , nous pouvons facilement passer à une interface utilisateur basée sur les tâches.
- Le protocole CQRS s'intègre parfaitement aux modèles de programmation événementielle. Il est courant de voir un système CQRS divisé en services distincts communiquant via une collaboration événementielle. Cela permet à ces services de tirer facilement parti d' une architecture pilotée par les événements .
- Le fait d'avoir des modèles distincts soulève des questions quant à la difficulté de maintenir la cohérence de ces modèles, ce qui augmente la probabilité d'utiliser la cohérence éventuelle.
- Dans de nombreux domaines, une grande partie de la logique requise est nécessaire lors des mises à jour ; il peut donc être judicieux d’utiliser la dérivation de lecture anticipée pour simplifier vos modèles côté requête.
- Si le modèle d'écriture génère des événements pour toutes les mises à jour, vous pouvez structurer les modèles de lecture comme des afficheurs d'événements, leur permettant d'être des images en mémoire et évitant ainsi de nombreuses interactions avec la base de données.
- CQRS est adapté aux domaines complexes, du type de ceux qui bénéficient également de la conception pilotée par le domaine .
Limites
CQS peut complexifier la mise en œuvre correcte des logiciels réentrants et multithreadés . Cela se produit généralement lorsqu'un modèle non thread-safe est utilisé pour implémenter la séparation commande-requête.
Voici un exemple simple qui ne respecte pas le CQS, mais qui est utile pour les logiciels multithread car il résout la complexité du verrouillage pour toutes les autres parties du programme ; cependant, ce faisant, il ne respecte pas le CQS car la fonction modifie et renvoie l'état :
Voici une version conforme à CQS. Notez qu'elle ne peut être utilisée en toute sécurité que dans des applications monothread. Dans un programme multithread, une condition de concurrence se produit dans l'appelant, entre les points d'appel de ` and` increment()et `is`.value()
Même dans les programmes monothread, il est parfois nettement plus pratique d'avoir une méthode qui combine requête et commande. Martin Fowler cite la pop()méthode d'une pile comme exemple.