---
title: "Separar Consulta de Modificador"
type: "refactoring-technique"
slug: "separate-query-from-modifier"
url: "http://localhost:3000/es/separate-query-from-modifier.md"
category: "Simplifying Method Calls"
description: "Problema: ¿Tienes un método que devuelve un valor pero también cambia algo dentro de un objeto? Solución: Divide el método en dos métodos independientes. Como es de esperar, uno de ellos debe devolver el valor y el otro modifica el objeto."
---
# Separar Consulta de Modificador

> Problema: ¿Tienes un método que devuelve un valor pero también cambia algo dentro de un objeto? Solución: Divide el método en dos métodos independientes. Como es de esperar, uno de ellos debe devolver el valor y el otro modifica el objeto.

## Problem

¿Tienes un método que devuelve un valor pero también cambia algo dentro de un objeto?

## Solution

Divide el método en dos métodos independientes. Como es de esperar, uno de ellos debe devolver el valor y el otro modifica el objeto.

## Why Refactor

Esta técnica de factorización implementa la _Segregación de Responsabilidad de Comando y Consulta_ (Command and Query Responsibility Segregation). Este principio nos indica que separemos el código responsable de obtener datos del código que cambia algo dentro de un objeto.

El código para obtener datos se denomina _consulta_. El código para cambiar cosas en el _estado visible_ de un objeto se denomina _modificador_. Cuando se combinan una _consulta_ y un _modificador_, no tienes forma de obtener datos sin alterar su condición. En otras palabras, haces una pregunta y puedes cambiar la respuesta incluso mientras la estás recibiendo. Este problema se vuelve aún más grave cuando quien llama a la consulta puede desconocer los “efectos secundarios” del método, lo que a menudo conduce a errores en tiempo de ejecución.

Pero recuerda que los efectos secundarios solo son peligrosos en el caso de los _modificadores_ que cambian el estado **visible** de un objeto. Estos podrían ser, por ejemplo, campos accesibles desde la interfaz pública de un objeto, una entrada en una base de datos, en archivos, etc. Si un _modificador_ solo almacena en caché una operación compleja y la guarda en el campo privado de una clase, difícilmente puede causar efectos secundarios.

## Benefits

* Si tienes una _consulta_ que no cambia el estado de tu programa, puedes llamarla tantas veces como quieras sin tener que preocuparte por cambios no intencionados en el resultado causados por el mero hecho de llamar al método.

## How to Refactor

1. Crea un nuevo _método de consulta_ que devuelva lo que hacía el método original.
2. Cambia el método original para que devuelva únicamente el resultado de llamar al nuevo _método de consulta_.
3. Reemplaza todas las referencias al método original con una llamada al _método de consulta_. Inmediatamente antes de esta línea, coloca una llamada al _método modificador_. Esto te protegerá de los efectos secundarios en caso de que el método original se usara en la condición de un operador condicional o de un bucle.
4. Deshazte del código que devuelve el valor en el método original, que ahora se ha convertido en un auténtico _método modificador_.
## Relations

**Helps you do**

- [Reemplazar Variable Temporal por Consulta](/es/replace-temp-with-query.md)