---
title: "Séparer la requête du modificateur"
type: "refactoring-technique"
slug: "separate-query-from-modifier"
url: "http://localhost:3000/fr/separate-query-from-modifier.md"
category: "Simplifying Method Calls"
description: "Problème : avez-vous une méthode qui renvoie une valeur mais modifie aussi quelque chose à l'intérieur d'un objet ? Solution : scindez la méthode en deux méthodes distinctes. Comme on peut s'y attendre, l'une doit renvoyer la valeur et l'autre modifier l'objet."
---
# Séparer la requête du modificateur

> Problème : avez-vous une méthode qui renvoie une valeur mais modifie aussi quelque chose à l'intérieur d'un objet ? Solution : scindez la méthode en deux méthodes distinctes. Comme on peut s'y attendre, l'une doit renvoyer la valeur et l'autre modifier l'objet.

## Problem

Avez-vous une méthode qui renvoie une valeur mais modifie aussi quelque chose à l'intérieur d'un objet ?

## Solution

Scindez la méthode en deux méthodes distinctes. Comme on peut s'y attendre, l'une doit renvoyer la valeur et l'autre modifier l'objet.

## Why Refactor

Cette technique de factorisation met en œuvre la _séparation des responsabilités entre commande et requête_ (Command and Query Responsibility Segregation). Ce principe nous dit de séparer le code chargé de récupérer des données du code qui modifie quelque chose à l'intérieur d'un objet.

Le code servant à récupérer des données est appelé une _requête_. Le code servant à modifier des éléments de l'_état visible_ d'un objet est appelé un _modificateur_. Lorsqu'une _requête_ et un _modificateur_ sont combinés, vous n'avez aucun moyen d'obtenir des données sans en modifier la condition. Autrement dit, vous posez une question et pouvez en changer la réponse au moment même où vous la recevez. Ce problème devient encore plus grave lorsque la personne qui appelle la requête peut ignorer les « effets de bord » de la méthode, ce qui conduit souvent à des erreurs à l'exécution.

Mais souvenez-vous que les effets de bord ne sont dangereux que dans le cas de _modificateurs_ qui changent l'état **visible** d'un objet. Il peut s'agir, par exemple, de champs accessibles depuis l'interface publique d'un objet, d'une entrée dans une base de données, dans des fichiers, etc. Si un _modificateur_ ne fait que mettre en cache une opération complexe et l'enregistrer dans un champ privé d'une classe, il ne peut guère provoquer d'effets de bord.

## Benefits

* Si vous disposez d'une _requête_ qui ne modifie pas l'état de votre programme, vous pouvez l'appeler autant de fois que vous le souhaitez sans avoir à craindre des changements involontaires du résultat causés par le simple fait d'appeler la méthode.

## How to Refactor

1. Créez une nouvelle _méthode de requête_ pour renvoyer ce que faisait la méthode d'origine.
2. Modifiez la méthode d'origine pour qu'elle ne renvoie que le résultat de l'appel à la nouvelle _méthode de requête_.
3. Remplacez toutes les références à la méthode d'origine par un appel à la _méthode de requête_. Juste avant cette ligne, placez un appel à la _méthode de modification_. Cela vous évitera des effets de bord au cas où la méthode d'origine était utilisée dans la condition d'un opérateur conditionnel ou d'une boucle.
4. Débarrassez-vous du code qui renvoie une valeur dans la méthode d'origine, qui est désormais devenue une véritable _méthode de modification_.
## Relations

**Helps you do**

- [Remplacer une variable temporaire par une requête](/fr/replace-temp-with-query.md)