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

12

Leí una vez 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 aprender más sobre ella.

¿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?

    
pregunta Wayne Conrad 16.07.2015 - 20:03

3 respuestas

13

Según Greg Young, esta idea se originó en Bertrand Meyer : Command- Separación de consultas .

  

Indica que cada método debe ser un comando que realice   una acción, o una consulta que devuelve datos a la persona que llama, pero no a ambos.   En otras palabras, Hacer una pregunta no debe cambiar la respuesta . 1   Más formalmente, los métodos deberían devolver un valor solo si son   referencialmente transparente y por lo tanto no posee efectos secundarios.

     

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

En Diseño impulsado por dominio, esto es similar a la Separación / Segregación de lectura de comando-consulta (CQRS), como lo nombró 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 / modificar de forma diferente a la parte de escritura (comando). Separar los dos evitaría que ambos se interpongan entre sí cuando la optimización / rendimiento es clave.

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

    
respondido por el tunmise fasipe 16.07.2015 - 20:51
4

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

Cualquier programa bien diseñado se dividirá en varias partes, se combinará y compondrá de varias maneras. Cuanto más difícil es razonar acerca de 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 la cantidad de efectos secundarios en cada parte que genera un efecto secundario hará que sea más fácil trabajar con esa parte de la misma manera.

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

    
respondido por el Morgen 16.07.2015 - 20:36
1
  

Crédito adicional: ¿Cuál es el beneficio de 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 corto evaluación del circuito .

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
}
    
respondido por el Nick Alexeev 16.07.2015 - 21:00

Lea otras preguntas en las etiquetas