Tornando * questo funzioni membro

Question

Recentemente ho usato una libreria che consente il seguente tipo di sintassi:

MyClass myObject; 
myObject 
    .setMember1("string value") 
    .setMember2(4.0f) 
    .setMember3(-1); 

Ovviamente ciò è ottenuto avente le incastonatori restituiscono un MyClass & tipo; qualcosa come return * this. Mi piace il modo in cui appare questo codice, ma non lo vedo molto. Quando ciò accade, di solito sono sospettoso sul perché.

Quindi, questa è una cattiva pratica? Quali sono alcune delle implicazioni di farlo in questo modo?

Answer 1

Questo è talvolta denominato Named Parameter Idiom o metodo di concatenamento. Questa non è una cattiva pratica, può aiutare la leggibilità. Considerate questo esempio sollevato dal C++ FAQ

File f = OpenFile("foo.txt") 
      .readonly() 
      .createIfNotExist() 
      .appendWhenWriting() 
      .blockSize(1024) 
      .unbuffered() 
      .exclusiveAccess(); 

L'alternativa sarebbe quella di utilizzare argomenti posizionali al metodo OpenFile, richiedendo al programmatore di ricordare la posizione di ciascun argomento.

Answer 2

Non c'è nessun problema con questo stile. L'unico svantaggio è che non è possibile utilizzare il valore restituito per scopi più tipici, come restituire il risultato della funzione.

Answer 3

Si chiama fluent api. Non è una cattiva pratica, solo uno stile di programmazione diverso.

Il più grande svantaggio (IMO) è che dal momento che si restituisce un riferimento a te stesso, non è possibile restituire altro e può essere difficile eseguire il debug delle dichiarazioni fluenti poiché sono viste dal compilatore come una "linea gigante" "di codice.

Answer 4

Non sono sicuro che sia considerata una cattiva pratica o meno, ma una delle implicazioni è che non è più possibile restituire codici di errore, quindi si è obbligati a utilizzare eccezioni o brutti oggetti di errore passati per riferimento. Le eccezioni a volte sono la soluzione giusta, ma spesso non lo sono, dal momento che possono essere costose da lanciare e sono disabilitate su alcune piattaforme.

Penso davvero che sia comunque una cosa stilistica, e grazie alla stretta relazione di C++ con C sia in sintassi che in cultura, molti programmatori C++ come i codici di errore preferiscono quindi restituirli invece di restituire un riferimento. Ma ho visto il ritorno di * questo spesso pure e non penso che sia una cattiva pratica.

Answer 5

In teoria, si potrebbe finire con un riferimento penzoloni se fai qualcosa di terribile come:

MyClass *myObject = new MyClass; 
MyClass & dangling = myObject->setMember1("string"); 
delete myObject; 
dangling.setMember2(yrParam); 

modo da essere consapevoli di questo.

Answer 6

È una pratica comune. Il sovraccarico di operator= implica a farlo per le chiamate a catena:

class Foo { 

public: 
    Foo& operator=(const Foo& f) { 
     if (this != &f) { // check for self-assignment 
     // do some stuff... 
     } 
     return *this; 
    } 

}; 

Questo codice consente di fare cose come:

Foo a, b, c; 
a = b = c; 

Si prega di notare che il controllo per l'auto-assegnazione è obbligatoria perché si deve spesso deallocare oggetti nell'oggetto corrente, quindi consentire a = a interromperà il codice.

Seguendo il commento di @Fred Nurk, vorrei aggiungere che si dovrebbe dare un'occhiata all'idioma Copy-and-Swap per evitare la duplicazione del codice e rilasciare un codice senza eccezioni.
Date un'occhiata al link qui di seguito per maggiori informazioni:

What is the copy-and-swap idiom?
http://gotw.ca/gotw/059.htm

Answer 7

Non male pratica, in realtà si vede spesso con flussi di uscita al fine di concatenare più stringhe e valori.

Lo svantaggio che vedo è che impedisce di restituire qualsiasi altra cosa, anche se è un metodo impostato, non dovrebbe avere importanza.

Answer 8

Alcune persone chiamano questa programmazione fluente (o un'interfaccia fluente). Altri lo chiamano un casino.

I tendere un po 'verso il secondo campo tendenzialmente. In particolare, la mia esperienza è stata che in molti casi, le persone che scrivono il codice in questo modo dipendono da sulla "fluente interfaccia" per un bel po 'di inizializzazione di un oggetto. In altre parole, nonostante il travestimento, è ancora in fase di inizializzazione. Allo stesso modo, anche se è probabilmente evitabile in molti casi, spesso sembra comportare un bel po 'di ciò che dovrebbe essere interamente privato alla classe che viene resa pubblicamente modificabile tramite manipolatori.

Personalmente I preferisco che gli oggetti siano immutabili dopo la creazione. Chiaramente non è sempre possibile, e in alcuni casi non puoi nemmeno avvicinarti molto. Ciononostante, quanto più gli interni di un oggetto si aprono alla manipolazione esterna, tanto meno si diventa certi che l'oggetto mantenga uno stato coerente (e, in genere, più lavoro si deve fare per mantenere uno stato coerente).

Answer 9

Il tuo esempio è non i parametri denominati idioma.

Con l'idioma dei parametri denominati, i settabili concatenabili impostano gli attributi di un pacchetto argomento (parametro).

Il tuo codice ha invece un gruppo di setter per la modifica dell'oggetto finale che stai costruendo, chiamato costruzione a due fasi.

In generale, la costruzione a due fasi è solo Bad ™ e la costruzione a due fasi implementata esponendo gli attributi al codice client, come nell'esempio, è Molto male ™.

Ad esempio, in genere non si desidera poter modificare gli attributi di un oggetto file, una volta che l'oggetto è stato creato (e possibilmente aperto).

Acclamazioni & hth.,