Stile di codifica dei parametri del metodo privato OOP

allow me to check at one look what member variables are used

L'uso di una firma del metodo esclusivamente per identificare i membri di una classe è uno stile di programmazione rozzo e non OO. OOP riguarda astrazioni e relazioni di livello superiore. Se riscontri problemi nel rintracciare un numero # ridicolo di membri, dovresti immediatamente rivedere le tue classi per assicurarti che abbiano uno scopo unico e facilmente identificabile. Sembra che tu stia costruendo oggetti divini .

Also, a change in code by removing a particular member variable can break **many** functions.

Un grande indicatore di accoppiamento stretto. Disaccoppia le tue classi Guarda iniezione di dipendenza. .

allow me to supply other values for tests and debugging.

Non chiaro sul significato qui. Soprattutto perché continui a dire

In this case however, the private function remains isolated am I can still call it using other values without fixing the function.

In generale, le funzioni private rendono il codice più difficile da test (unitario) non più semplice. Hai familiarità con Mocking ? Stai provando con test unitari , una specie di birra fatta in casa o altro?

Is this a bad idea afterall, especially in a team environment?

Direi che è una pratica almeno discutibile che potrebbe portare a problemi, in particolare in un ambiente di squadra. Avendo lavorato in questo modo per un po 'di tempo, potresti aver sviluppato abitudini e comprensione che evitano i potenziali problemi, ma i membri del team probabilmente non capiranno le tue regole non scritte.

In particolare, sembra che tu stia essenzialmente praticando la programmazione procedurale in un ambiente orientato agli oggetti. Il punto degli oggetti è che contengono sia i dati che le operazioni su quei dati. Ad esempio, se si dice a draw (), ad esempio, non è necessario dirgli cosa disegnare - deve disegnare da sé. Se devi dirgli cosa disegnare, non stai sfruttando la potenza di OOP.

Un pericolo del tuo approccio è che i tuoi metodi non operano sui membri dell'oggetto, ma sui parametri. Se si passano tali parametri in base al valore, le eventuali modifiche apportate a tali parametri non si rifletteranno nelle corrispondenti variabili membro. Puoi risolvere il problema passando per riferimento, ma in tal caso il tuo codice potrebbe cambiare le variabili membro se questo è ciò che passi, ma non è ovvio che sia quello che sta succedendo. Peggio ancora, c'è la possibilità molto reale che il chiamante passi in qualcosa di diverso da una variabile membro, il che cambia davvero il significato di ciò che fa il metodo.

Is it like redundant or confusing

• Ridondante: sicuramente.
• Confusione: apparentemente non a te, ma sicuramente agli altri.

are there better ways?

Utilizza le variabili membro o le proprietà anziché i parametri nei metodi che sono destinati a operare sui dati memorizzati all'interno dell'oggetto. Utilizza i parametri per informazioni esterne all'oggetto.

Se hai difficoltà a discernere quali membri utilizzano un determinato metodo, prova uno dei seguenti:

• Metti un commento vicino all'inizio del metodo che spiega cosa fa il metodo, elenca i membri interessati e forse descrive qualsiasi output.

• Semplifica i tuoi metodi. Sono tutti per i commenti appropriati, ma il codice è molto più bello quando puoi scansionare velocemente il codice e avere una buona idea di cosa sta succedendo.

• Smetti di preoccupartene. Un metodo dovrebbe utilizzare qualsiasi dato interno di cui ha bisogno per svolgere il proprio lavoro. Il codice al di fuori del metodo dovrebbe essere più interessato a cosa fa il metodo, non a come lo fa.

Se vuoi avere la funzione in classe (privata o meno, non importa), usa i membri come membri, in modo che sia un'operazione della classe. Altrimenti, in linea di principio, non appartiene alla classe. Mettilo fuori classe e chiamalo con un sacco di parametri. Se ritieni che sia un aiuto che "deve funzionare indipendentemente dal modo in cui la classe viene refactored".

In generale, non è una buona idea dare ai metodi (o a qualsiasi altra cosa) accesso alle informazioni che non è necessario. Avere una lunga lista di parametri significa spulciarne di più quando tu o qualcun altro hai bisogno di trovare qualcosa. Se sono sicuramente correlati e necessari, forse dovresti prendere in considerazione la creazione di un oggetto da passare o il passaggio dell'oggetto da cui provengono.

Per quanto riguarda i test, dovresti provare a tenere i test separati dalla tua logica effettiva.

Come altri hanno sottolineato, ciò che descrivi sembra andare contro l'idea degli oggetti, per una spiegazione esaustiva di ciò, raccomanderei a Robert C. Martins di scrivere "Clean Code", in particolare il capitolo sui metodi.

È importante perché è una descrizione completa e pratica di come scrivere un codice orientato agli oggetti pulito. Il capitolo di riferimento in particolare discute gli elenchi dei parametri dei metodi riguardanti:

• la loro lunghezza,
• la responsabilità del metodo,
• la responsabilità della classe,
• e le variabili di istanza.

Questo capitolo contiene una lunga risposta alla domanda. La risposta breve è di avere pochi parametri, per favorire le variabili di istanza e per mantenere le lezioni molto focalizzate - questo è in accordo con il Principio della singola responsabilità .