Miscelazione di un'interfaccia fluente e non fluente in una classe

Question

Considero le interfacce fluenti molto convenienti per molte attività. Ma mi sento a disagio quando finisco per mescolare metodi fluenti e metodi di modifica in una classe.

Solo un esempio (è un po 'forzato, si prega di portare con me):

Ipotizzando una classe di utilità stringa, rifilatura sembra buono per il concatenamento:

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

Altri metodi sarebbe naturalmente restituire un nuovo oggetto :

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

e c'è un terzo tipo, che - di per sé - sarebbe logicamente mutare l'oggetto e ret urna uno nuovo:

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

Quando uso la firma che è più evidente per ogni metodo individualmente, io alla fine con questi tre tipi, e temo che non è molto intuitivo per consumare la classe che è che, specialmente dal momento che il tipo di ritorno è mroe o meno uguale.

---

ho già deciso di non fare Str immutabile - dal momento che metodi come SplitToken forniscono funzionalità di base. Il mio problema principale è mescolare metodi fluenti Cosa faresti?

• non usano metodi fluente in tale interfaccia

• loro

  passare ad un sub-interfaccia (vedi sotto)

• "Se uno è fluente, tutti i metodi di modifica dovrebbero essere fluente"?

• utilizzare un prefisso seocifico per i metodi fluenti?

• non ti preoccupare?

• ??? Interfaccia

sub idea:

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

Sono indeciso su questo, mi piace non è davvero il più "fluida" - soprattutto che si tratta di una chiamata di metodo in C++

Cosa fare tu pensi?

[modifica] Sto usando "fluente" qui nel significato di base del concatenamento di chiamate di metodo su una singola istanza, non nel senso avanzato della creazione di frasi inglesi nel codice.

Answer 1

Non ho lavorato molto con le interfacce fluenti (anche se ho giocato con le DSL in generale), ma mi sembra che mentre la classe può prestarsi a questo approccio, non è particolarmente necessario in questo caso . Forse mi manca qualcosa, ma mi sembra che non sia probabile che tu stia facendo un sacco di azioni su una singola stringa senza alcun riferimento a qualcos'altro, che è quello con cui sei finito qui.Inoltre, si sta transizione a nuovi oggetti al centro della catena, che sembra ancora una volta a violare lo scopo di un'interfaccia fluida, soprattutto se si considera ciò che accade in questa catena:

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

penso che forse questo tipo di classe di utilità di livello relativamente basso è il posto sbagliato per provare un'interfaccia fluente. Fluency mi sembra molto più importante quando i tuoi oggetti sono soggetti a un'attenzione concentrata e persistente rispetto a quando sono transitori e accessori alla logica principale.