Funzioni private C++: se passare la variabile membro della classe in base al parametro funzione, oppure no

Question

Ecco una domanda che si presenta ancora e ancora nell'implementazione della classe C++. Sono curioso di sapere quali sono i pensieri delle persone qui. Quale codice preferisci e perché?

class A 
{ 
public: 
    /* Constructors, Destructors, Public interface functions, etc. */ 
    void publicCall(void); 

private: 
    void f(void); 

    CMyClass m_Member1; 
}; 

con

void A::publicCall(void) 
{ 
    f(); 
} 

void A::f(void) 
{ 
    // do some stuff populating m_Member1 
} 

Oppure l'alternativa:

class A 
{ 
public: 
    /* Constructors, Destructors, Public interface functions, etc. */ 
    void publicCall(void); 

private: 
    void f(CMyClass &x); 

    CMyClass m_Member1; 
}; 

con

void A::publicCall(void) 
{ 
    f(m_Member1); 
} 

void A::f(CMyClass &x) 
{ 
    // do some stuff to populate x, 
    // locally masking the fact that it's really m_Member1 
} 

Credo che preferisco sempre la seconda perché poi f può quindi operare su qualsiasi istanza di CMyClass ma, detto questo, ho un sacco di codice in cui il primo è perfettamente valido dal f funzionerà sempre su m_Member1 e lo sto davvero suddividendo in due funzioni per rendere il codice più leggibile.

Sì, questa è più una domanda di discussione che una domanda di "risposta", ma sono più interessato al ragionamento. Contrassegnerò come risposta una risposta che dia un buon ragionamento o un buon criterio.

Inoltre, tieni presente che questo è solo un esempio di giocattolo. La classe sarà più grande di questa realtà e quindi l'organizzazione è importante.

Answer 1

Chiediti: ha qualche significato ora o può avere un significato nel futuro prevedibile, per chiamare f() con un oggetto diverso da m_Member1?

Se la risposta è:

• No. Un valore m_Member1 senza parametro è una parte intrinseca di A.
• Sì. Fai il f(CMyClass &). Anche se ora usi solo m_Member1, questa non è una proprietà intrinseca delle classi che gestisci.
• Forse. Beh ... direi di andare con l'f() senza parametri. C'è sempre la possibilità di cambiare idea (il cambiamento se abbastanza banale, in realtà).

Si noti inoltre che una funzione f() può chiamare un'altra funzione g(CMyClass &), ma non viceversa. Quindi, a seconda di cosa fa f(), ciò potrebbe limitare le tue opzioni.

Answer 2

Dato che chiedi opinioni, se una funzione autonoma f(CMyClass&) ha senso ed è implementabile, allora vorrei anche favorire questa opzione. Opterei per il primo caso se l'operazione eseguita da f ha senso solo nel contesto della classe A, se CMyClass ha senso solo nel contesto di A, o se dipende da altri attributi di A. Penso che si debba decidere a seconda del problema.

Answer 3

Non è f nel secondo esempio meglio di una funzione statica di A o funzione globale o, forse, una funzione membro di CMyClass?

Ovviamente, ci sono casi in cui è meglio inviare l'argomento ogni volta che si chiama tale funzione, ma perché dovresti inviarlo di nuovo quando hai già un oggetto CMyClass nell'oggetto A. Se è necessario interagire con entrambi gli oggetti CMyClass, è preferibile aggiungerlo all'elenco delle funzioni membro CMyClass anziché a A.

Inoltre, come Clean Code stati, è meglio con funzioni senza argomenti, che con quelli con argomenti. Quando un altro programmatore tenta di leggere la funzione, deve decifrare/prestare attenzione al secondo parametro, oltre al nome della funzione.

Answer 4

Vorrei basare la risposta sul contesto. Se ci sono ora o potrebbero essere in qualche giorno più istanze di variabili membro su cui possa operare f, quindi sicuro, passarle/loro come parametri. Tuttavia, se f sta operando su elementi specifici dello stato dell'istanza di A, non vorrei passare nulla ad esso. Ci sono molti casi in cui ci sarà sempre un solo foo in una A. A quel punto diventa sciocco rendere foo un parametro a f. E un po 'meno efficiente, a meno che f non sia in linea, poiché non solo viene passato questo puntatore, ma anche l'indirizzo di foo, che è una copia extra nello stack.

Answer 5

Come sempre, dipende. Ogni scenario è diverso.

Nell'esempio specifico che hai fornito - in primo luogo escluderei la tua alternativa (void A::f(CMyClass &x)) principalmente perché "odora" male (come dice Martin Fowler). È una funzione privata e, a meno che non sia necessario utilizzarlo, ora per altre istanze, utilizzarlo. Puoi sempre refactoring in caso di necessità.

Immaginate cosa succederebbe se f avesse 2 parametri. 3 parametri. 10. Avrebbe senso quindi inviarli ogni volta? Non sarebbe meglio avere questi parametri membri?

E cosa succede se f ha dovuto inviare alcuni di questi argomenti ad altri metodi di A? Non ha più senso usare i membri per questo?

Tutto ciò presuppone che f abbia bisogno di altre informazioni che contiene A, altrimenti lo sposterei come metodo CMyClass.