Vale la pena estrarre metodi privati per il codice che viene chiamato solo una volta in una classe, o lasciando il codice nel metodo genitore (forse) con un commento che dice che cosa fa?Dovresti rifattorizzare il codice in metodi privati se non vengono chiamati più di una volta?
Vale sempre la pena estrarre metodi se chiarisce l'intento del codice.
Ciò è particolarmente vero per i metodi molto lunghi. Sebbene i commenti vadano bene, non vengono delineati (almeno non in modo molto solido) dove il processo spiega e dove inizia quello successivo. A volte le astrazioni comuni diventano solo più ovvie dopo il hai estratto il metodo.
Se si eseguono test unitari automatizzati (non necessariamente TDD), sarà anche molto, molto più facile testare unitamente più blocchi di metodi, anche se potrebbe essere necessario rendere pubblici i propri metodi, a seconda del quadro di test che usi.
Il punto è che non puoi sbagliare con i metodi più piccoli, soprattutto se hanno nomi descrittivi.
Sono molto d'accordo. Ho sempre un refactoring in questo modo e il grado in cui aggiunge la leggibilità al codice è tremendo. L'astrazione è molto utile anche fino al livello di un metodo breve (ad esempio 1 riga). Refactoring in questo modo rende enormemente più facile vedere il flusso del tuo metodo originale e cambiare la progettazione o l'implementazione del metodo principale o di qualsiasi suo componente. – Wedge
Ho pensato a questa risposta. Penso che dovresti cambiare "non puoi sbagliare con i metodi più piccoli, specialmente se hanno nomi descrittivi". a "Puoi sbagliare solo se i metodi NON hanno un nome descrittivo" – mcintyre321
Naturalmente! Più piccoli sono i tuoi metodi, più facile mantenere il tuo software.
Cosa c'è che non va con le 1-liners? Se questo è il livello di incapsulamento di cui hai bisogno, allora è quello. Credere che un metodo a 1 linea non sia "abbastanza carnoso" per essere un "metodo reale" è intellettualmente limitante. Inizia a cercare i metodi a 1 riga che possono essere estratti e che sarebbero utili, probabilmente troverai più di quanto penseresti. – Wedge
Sì, hai assolutamente ragione, non avrei dovuto dire "(Beh, le battute non sarebbero troppo utili ovviamente.)" In un modo così definitivo ... Non so come scriverlo meglio allora l'hai già fatto, quindi credo che rimuoverò quella frase. :-) Grazie! – Arjan
C'è un enorme vantaggio in questo. Si tratta di nascondere le informazioni e chiarire le intenzioni.
In Refactoring to Code hanno chiamato questo metodo di composizione in cui si interrompe un metodo di grandi dimensioni in molti metodi più piccoli. Questo fa due cose.
Prima riduce la quantità di informazioni che è necessario preoccuparsi quando si lavora sul metodo genitore.
In secondo luogo, il nome del metodo deve indicare la sua intenzione che rende il codice più leggibile.
Inoltre, rende molto, molto più semplice, i problemi relativi all'ambito variabile. Scansionare 100 righe di codice per scoprire dove vengono utilizzate le variabili è una perdita di tempo non banale rispetto all'esame di un metodo che è meno di una dozzina di righe. – Wedge
Sì, lo è.
Un altro punto: Per semplici metodi di supporto, si potrebbe desiderare di farli statico (in modo tale che essi non dipendono o alterare lo stato del loro esempio), allora si può renderli pubblici per ancora più facile riutilizzo.
Per me dipende dall'ampiezza del codice e dalla relazione con il metodo padre. Se è molto codice (diciamo più di 5-10 righe di codice, o più del 50% della quantità totale di codice nel metodo genitore), lo estraggo in un metodo privato, per la struttura del codice e la leggibilità. Altrimenti lo lascerei nel metodo genitore con un commento descrittivo.
Penso che la manutenibilità e la leggibilità possano essere ridotte se nel codice ci sono troppi metodi molto piccoli. Mi sforzo per un buon equilibrio. Ma ogni volta che dubito; Lo estro come metodo privato.
Solo una stima stupida, ma direi che la maggior parte dei metodi privati viene chiamata solo in un paio di posti nella classe media. Tuttavia, come accennato in precedenza, rende il codice molto più leggibile e più facile da testare/mantenere se si rompono tutte le funzionalità in blocchi logici.Il refactoring è una buona abitudine
Si dovrebbe refactoring privato in base al design della tua API & metodi/proprietà che si desidera esporre quando si utilizza altrove. Non dovresti considerare il suo utilizzo per decidere se renderlo privato o pubblico.
In qualche ideale astratto non ci sarebbero commenti. O quello, o il tuo * commento * sarebbe il codice ala Programmazione letteraria di Knuth. –