Origen de "un método debe devolver un valor o tener efectos secundarios, pero no ambos"

Una vez leí que un método debería tener un valor de retorno (y ser referencialmente transparente) o tener efectos secundarios, pero no ambos. No puedo encontrar ninguna referencia a esta regla, pero quiero obtener más información al respecto.

¿Cuál es el origen de este consejo? ¿De qué persona o comunidad surgió?

Crédito adicional: ¿Cuál es el beneficio reclamado de seguir este consejo?

Según Greg Young, esta idea se originó a partir de Bertrand Meyer : separación entre comando y consulta .

Establece que cada método debe ser un comando que realiza una acción o una consulta que devuelve datos al llamante, pero no ambos. En otras palabras, hacer una pregunta no debería cambiar la respuesta . ¹ Más formalmente, los métodos deberían devolver un valor solo si son referencialmente transparentes y, por lo tanto, no poseen efectos secundarios.

1: Eiffel: un lenguaje para la ingeniería de software diapositiva 43-48

En el diseño impulsado por dominio, esto es similar a la separación / segregación comando-consulta-lectura (CQRS), como lo nombra Greg Young.

Greg Young tomó la idea de CQS de Bertrand para nombrar CQRS como lo menciona Martin Fowler en este artículo de CQRS

Beneficios

• La parte de lectura (consulta) se puede escalar / ajustar de manera diferente a la parte de escritura (comando). Separar los dos evitaría que cualquiera se interpusiera entre sí cuando la optimización / rendimiento es clave.

Lea el artículo en el enlace de Martin Fowler para más información.

No sé de dónde viene, pero es un buen consejo y bastante sencillo de entender.

Cualquier programa diseñado de manera sensata se dividirá en varias partes, combinadas y compuestas de varias maneras. Cuanto más difícil sea razonar sobre lo que hace una parte en particular, más difícil será asegurarse de que su programa reaccionará de manera predecible.

Aislar las partes que producen efectos secundarios hace que el resto sea más fácil de razonar, probar y depurar. Reducir el número de efectos secundarios en cada parte que genera un efecto secundario hará que esa parte sea más fácil de trabajar de la misma manera.

Si lo descompone aún más, un valor de retorno es un efecto. Los efectos secundarios son un efecto. Una función solo debería producir 1 efecto (si es posible) porque cuanto mayor sea el número de entradas y efectos que tenga una función, mayor será la dificultad de razonar sobre lo que realmente hace.

Crédito adicional: ¿Cuál es el beneficio originalmente reclamado de seguir este consejo?

Uno de los beneficios de separar el valor de retorno de los efectos secundarios es que elimina un problema potencial que puede ser causado por la evaluación de cortocircuito .

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}