Mezcla de una interfaz fluida y no fluida en una clase

Question

Considero que las interfaces fluidas son muy convenientes para muchas tareas. Pero me siento incómodo cuando termino mezclando métodos fluidos y modificando métodos en una clase.

Sólo un ejemplo (que es un poco artificial, por favor tengan paciencia conmigo):

Suponiendo una clase de utilidad cadena, el recorte parece buena para encadenar:

Str & Str::Trim() { return TrimLeft().TrimRight(); } 

Otros métodos naturalmente devolver un nuevo objeto :

Str Str::GetFirstToken() const 
{ 
    // result = first token; 
    return result; 
} 

y hay una tercera tipo, que - por sí mismo - lógicamente sería mutar el objeto y ret urna una nueva:

Str Str::SplitFirstToken() 
{ 
    result = GetFirstToken(); 
    // this = remainder 
    return result; 
} 

Cuando uso la firma que es más obvio para cada método de forma individual, termino con estos tres tipos, y me temo que no es muy intuitiva para el consumo de la clase que es la que, especialmente porque el tipo de retorno es menos o menos igual.

---

ya he decidido no hacer Str inmutable - ya que los métodos como SplitToken proporcionan la funcionalidad básica. Mi problema principal es mezclar métodos fluidos ¿Qué harías?

• no utilizan métodos fluidez en esa interfaz

• moverlos a una sub-interfaz (ver más abajo)

• "Si uno es fluido, todos los métodos de modificación debe ser fluido"?

• usa un prefijo seocífico para los métodos fluidos?

• no te preocupes?

• ???

sub idea de interfaz:

void CStr::Trim() { TrimLeft(); TrimRight(); } 
CStrFluent & Str::Fluent() { return CStrFluent(*this); } 
.... 
str.Fluent().TrimLeft().TrimRight(); 

estoy indeciso sobre esto, yo realmente no me gusta el extra "fluidez" - sobre todo que se trata de una llamada de método en C++

Qué hacer ¿Crees?

[edit] Estoy usando "fluido" aquí en el significado básico de las llamadas al método de encadenamiento en una sola instancia, no en el sentido avanzado de crear oraciones en inglés en el código.

Answer 1

No he trabajado mucho con interfaces fluidas (aunque he jugado con DSL en general), pero me parece que si bien la clase puede prestarse a este enfoque, no es particularmente necesario en este caso . Tal vez me esté perdiendo algo, pero me parece que no es probable que estés haciendo un montón de acciones en una sola cadena sin referencia a nada más, que es con lo que terminaste aquí.Además, realiza la transición a los nuevos objetos en el medio de la cadena, que parece de nuevo para violar el propósito de una interfaz fluida, sobre todo si tenemos en cuenta lo que sucede en esta cadena:

Str String = OtherString.GetFirstToken().SplitFirstToken().Trim(); 

Creo que tal vez este tipo de clase de utilidad de nivel relativamente bajo es el lugar equivocado para probar una interfaz fluida. La fluidez me parece mucho más importante cuando los objetos están sujetos a una atención enfocada y persistente que cuando son transitorios y ancilares a la lógica central.