getter e setter stile

Question

(lasciando da parte la questione di se li hanno affatto).

ho sempre preferito utilizzare solo la funzione sovraccarico per darvi lo stesso nome sia per getter e setter.

int rate() { return _rate; }  
void rate(int value) { _rate = value; } 

// instead of  
int getRate() { return _rate; }  
void setRate(int value) { _rate = value; } 

// mainly because it allows me to write the much cleaner  
total(period() * rate());  
// instead of  
setTotal(getPeriod() * getRate()); 

Naturalmente, ho ragione, ma mi chiedevo se gli scrittori della biblioteca avessero una buona ragione?

Answer 1

Preferirei le versioni get/set perché è più chiaro su cosa sta succedendo. Se ho visto rate() e rate (10), come faccio a sapere che rate (10) non sta semplicemente usando 10 nel calcolo per restituire il rate? Io no, quindi ora devo iniziare a cercare per capire cosa sta succedendo. Un nome di una singola funzione dovrebbe fare una cosa, non due cose opposte.

Inoltre, come altri hanno fatto notare, alcuni preferiscono omettere il 'get' e lasciare il 'set', vale a dire,

int Rate(); 
void SetRate(int value); 

Tale convenzione è abbastanza chiaro così, non avrei alcun problema a leggerlo.

Answer 2

Mentre il commento di Ed è vero, preferisco le proprietà effettive al setter/getter antipattern. Quando 1/3 dei metodi nel tuo dominio grafico sono metodi fittizi che sono stati generati da Eclipse, c'è qualcosa di sbagliato.

Senza proprietà di prima classe, tuttavia, credo che l'antipattern abbia più senso.

Inoltre, facilita il completamento del codice.

obj.set (control shift space) per setter
obj.get (control shift space) per getter

Answer 3

ho sempre preferito omettere il 'get' sul mio getter, come si fa, con rate() invece di getRate(). Ma sovraccaricare il setter non mi sembra una buona idea, dal momento che il nome rate non comunica che l'oggetto è stato mutato. Considerate:

total(period() * rate()); // awesome, very clear 

rate(20); // Looks like it computes a rate, using '20'...but for what? And why ignore the return value? 

Answer 4

Come su int rate(); e void setRate(int value);? Questo ha il merito di non avere due funzioni con lo stesso nome facendo cose diverse, e comunque permette di period() * rate().

Answer 5

Alcuni anni fa, avrei acconsentito completamente. Più recentemente, un dubbio ha iniziato a farsi strada, perché ciò rende ambiguo il discorso di un getter o setter. Con strumenti come tr1 :: bind, questo è davvero fastidioso.

Ad esempio:

struct A 
{ 
    void Foo(int); 
    int Foo()const; 
}; 

std::vector<A> v = ....; 
std::vector<int> foos; 
// Extract Foo 
std::transform(
    v.begin(), v.end(), 
    std::back_inserter(foos), 
    //Ambiguous 
    // std::tr1::bind(&A::Foo) 
    //must write this instead. Yuck! 
    std::tr1::bind(static_cast<int(Foo::*)()>(&A::Foo)); 
); 

Lasciando da parte la questione della loro dovrebbe avete affatto ;-)

Answer 6

io vado avanti e citato questo dovrebbe essere una questione della comunità wiki.

Quando ho iniziato a imparare C++ ho cercato guide di stile, e Google era buono per alcuni punti:

• Methods in maiuscolo (è solo più bella).
• getter chiari e minuscoli (rate).
• setter esplicitamente e minuscole (setRate).

Answer 7

Essere concisi è importante, ma non a costo di essere incompleto o fuorviante. Per questo motivo, preferisco GetFoo() e SetFoo() a Foo() e Foo (int foo).

Answer 8

Personalmente, penso che getter e setter si trovano in coppie sono un odore di codice riportati dal lingue "visivi" e le loro "proprietà". In una classe "buona", i membri di dati sono writeonly o readonly ma non di lettura/scrittura.

Penso che la causa più comune di getter e setter non sta portando il modello a oggetti abbastanza profonda. Nel tuo esempio, perché viene passato il totale e il tasso? Non sono membri della classe? Quindi dovresti impostare solo il periodo e il tasso e dovresti ottenere solo un totale.

Probabilmente ci sono delle eccezioni, ma ho solo odio guardando una classe e di trovare "GetX/setX, Gety/Sety, ecc ecc" Sembra solo che non ci fosse abbastanza pensiero su come la classe DOVREBBE essere usata e piuttosto l'autore ha reso la classe EASY per ottenere i dati in modo che non avrebbe dovuto considerare come la classe dovrebbe essere utilizzata.

Naturalmente ho ragione.

Answer 9

Ci sono diversi livelli di "ricevere" e "Impostazione"

• Io uso Get e Set per le operazioni di "veloci".
• Se qualcosa ci vorrà più tempo per l'esecuzione, allora sarà spesso una Calc, come questi nomi implica che un certo lavoro deve essere fatto per recuperare il risultato.
• Per le operazioni più lunghe, si inizia a entrare in prefissi come Load/Save, Query/Store, lettura/scrittura, Ricerca/Trova ecc

Quindi get/set può essere attribuito un significato utile, ed essere parte di una strategia di denominazione più ampia e coerente.

Answer 10

Applico la convenzione in cui un metodo dovrebbe sempre essere un verbo e una classe dovrebbe sempre essere un nome (ad eccezione dei funtori, per ovvi motivi). In tal caso, deve essere utilizzato un prefisso get/set per coerenza. Detto questo, sono anche d'accordo completamente con Ed Swangren. Questo mi ha dato l'idea di usare quei prefissi un gioco da ragazzi.

Answer 11

Un altro problema che nessun altro ha menzionato è il caso di sovraccarico di funzione. Prendete questo esempio (artificioso e incompleto):

class Employee { 
    virtual int salary() { return salary_; } 
    virtual void salary(int newSalary) { salary_ = newSalary; } 
}; 

class Contractor : public Employee { 
    virtual void salary(int newSalary) { 
     validateSalaryCap(newSalary); 
     Employee::salary(newSalary); 
    } 
    using Employee::salary; // Most developers will forget this 
}; 

Senza che using clausola, gli utenti di Contractor non possono interrogare lo stipendio a causa del sovraccarico. Di recente ho aggiunto -Woverloaded-virtual al set di avvertenze di un progetto su cui lavoro, ed ecco che questo è apparso dappertutto.

Answer 12

Preferisco evitare le etichette get e set, l'informazione non è necessaria perché il compilatore faccia il suo lavoro per la maggior parte di queste semplici proprietà.

si può avere problemi:

class Stuff { 
    void widget(int something); // 'special' setter 
    const Widget& widget(int somethingelse) const; // getter 
} 
Stuff a; 
a.widget(1); // compiler won't know which widget you mean, not enough info 

Answer 13

Se il getter è semplicemente rate(), il compilatore si lamentava che il suo una ridefinizione del vostro altro rate simbolo, a condizione che hai dato il tuo campo di un buon nome significativo come quello. In tal caso è necessario fare qualcosa di sciocco come il nome del membro _rate o qualche altro approccio simile. Personalmente odio vedere/digitare quei caratteri di sottolineatura, quindi tendiamo ad adottare l'approccio getRate().

Questo è ovviamente soggettivo e questa è la mia preferenza personale.