Séparation commande-requête

La séparation commande-requête est particulièrement bien adaptée à une méthodologie de conception par contrat (DbC), dans laquelle la conception d'un programme est exprimée sous la forme d'assertions intégrées dans le code source, décrivant l'état du programme à certains moments critiques. Dans la DbC, les assertions sont considérées comme des annotations de conception – et non comme une logique de programme – et en tant que telles, leur exécution ne devrait pas affecter l'état du programme. La CQS est bénéfique pour la DbC parce que la valeur de retour de la méthode (toute requête) peut être appelée par n'importe quelle assertion sans crainte de modifier l'état du programme.

En termes théoriques, cela établit une mesure de cohérence, par laquelle on peut raisonner sur l'état d'un programme sans modifier simultanément cet état. Concrètement, la CQS permet de contourner tous les contrôles d'assertions dans un système fonctionnel pour améliorer ses performances sans modifier involontairement son comportement. La CQS peut également prévenir l'apparition de certains types de heisenbugs.

Même au-delà du lien avec la conception par contrat, la CQS est considérée par ses adhérents comme ayant un effet simplificateur sur un programme, rendant ses états (via des requêtes) et les changements d'états (via des commandes) plus compréhensibles.

La CQS est bien adaptée à la méthodologie orientée objet, mais peut également être appliquée en dehors de la programmation orientée objet. Comme la séparation des effets secondaires et des valeurs de retour n'est pas intrinsèquement orientée objet, la CQS peut être appliquée de façon rentable à tout paradigme de programmation qui exige un raisonnement sur les effets secondaires.

La CQS peut rendre plus difficile à mettre en œuvre correctement des logiciels réentrants et multithread. Cela se produit généralement lorsqu'un patron de conception non thread-safe est utilisé pour mettre en œuvre la séparation commande–requête.

Voici un exemple simple d'un modèle qui casse les principes CQS mais qui est utile pour les logiciels multi-threaded. Il casse les principes CQS parce que la fonction à la fois mute l'état et le renvoie :

private int x;
public int increment_and_return_x() {
  lock x;   // by some mechanism
  x = x + 1;
  int x_copy = x;
  unlock x; // by some mechanism
  return x_copy;
}

Voici un modèle conforme à la CQS. Cependant, il n'est utilisable en toute sécurité que dans des applications mono-thread. Dans un programme multithreadé, il y a une situation de compétition dans l'appelant, entre le moment où seraient appelés increment() et value() :

private int x;
public int value() {
  return x;
}
void increment() {
  x = x + 1;
}

Même dans les programmes mono-thread, il est parfois beaucoup plus pratique d'avoir une méthode qui est une requête et une commande combinées. Martin Fowler cite la méthode pop() d'une pile comme exemple[2].

• Interface fluide

(en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Command–query separation » (voir la liste des auteurs).

• Explication sur le BLiki de Martin Fowler
• CQRS Journey by Microsoft patterns & practices
• DDD/CQRS/Event Sourcing Liste
• Questions fréquemment posées sur la CQRS
• CQRS - a new architecture precept based on segregation of commands and queries