¿Son las interfaces fluidas una violación del Principio de Separación de Consulta de Comando?

Question

Empecé a escribir una interfaz fluida y eché un vistazo a una pieza más antigua que Martin Fowler escribió en interfaces fluidas (que no me di cuenta que él y Eric Evans acuñaron el término). En la pieza, Martin menciona que los instaladores generalmente devuelven una instancia del objeto que se está configurando o en el que se está trabajando, lo que él dice es una violación de CQS.

La convención común en el mundo corchete es que modificador métodos son nulos, lo que me gusta, ya que sigue el principio de Command-Query Separation. Esta convención se interpone en el camino de una interfaz fluida , por lo que estoy dispuesto a suspender la convención para este caso .

Así que si mi interfaz fluida hace algo como:

myObject 
    .useRepository("Stuff") 
    .withTransactionSupport() 
    .retries(3) 
    .logWarnings() 
    .logErrors(); 

¿Es esta realmente una violación de SCC?

ACTUALIZACIÓN Apagué mi muestra para mostrar las advertencias de registro y los errores como comportamientos separados.

Answer 1

No. El patrón aquí es "Configuración". Dichos comandos de configuración devuelven el objeto de configuración como algo opuesto a algo no relacionado con el comando. Una violación de la segregación de comandos/Consulta ocurriría si los comandos que sirven el propósito de configuración devueltos algunos datos no relacionados, por ejemplo:

if (myObject.UseRepository("Stuff") > 1 && myObject.UseRepository("Bla") < 5) { 
    // oh, good, some invisible stuff internal to myObject is in right interval... 
} 

Answer 2

Sí, lo es. Todos esos métodos obviamente devuelven algo, e igualmente obviamente tienen efectos secundarios (a juzgar por el hecho de que no hace nada con el valor de retorno, sin embargo, se molesta en llamarlos). Dado que la definición de CQS establece que los mutadores no deben devolver un valor, tenemos una violación clara en nuestras manos.

¿Pero le importa a usted que se haya violado el CQS? Si la interfaz fluida lo hace más productivo considerando todo, y si lo considera un patrón bien conocido con beneficios e inconvenientes igualmente conocidos, ¿por qué debería importar si viola el principio X en papel?

Answer 3

Viola este principio cuando cambia objetos pero no cuando solo devuelve un objeto nuevo.

var newObject = myObject 
    .useRepository("Stuff") 
    .withTransactionSupport() 
    .retries(3) 
    .logWarningsAndErrors(); 

Si myObject es sin cambios después de esta declaración, todo está bien. Generalmente hablado, una interfaz fluida viola el principio CQS, si, y solo si tiene efectos secundarios.

Sin embargo, la pregunta es si su ejemplo representa una consulta. ¿"Fluido" significa necesariamente "consulta"? Probablemente podría simplemente ser percibida como una interfaz fluida de acción donde el mismo objeto pasa de una acción a la siguiente.