Prenderò per scontato che la tua funzione bisect() sia un metodo della classe che hai menzionato e che assomigli a questo:
def bisect()
while self.word_wrap() == False:
pass
Per quanto riguarda il metodo word_wrap() , proporrei di suddividerlo in metodi più piccoli perché i metodi più piccoli sono:
1. Più semplice da testare
Immagina di scrivere un test unitario per il tuo metodo word_wrap() . Dovrai testare se:
- il testo è suddiviso correttamente in righe
- le righe sono suddivise in parole correttamente
- il controllo della lunghezza della linea funziona davvero per ogni tipo di input (ad esempio, una riga senza parole su di esso)
- il calcolo dell'altezza funziona come previsto
- l'oggetto font restituito ha le proprietà e i valori corretti
Scrivere un test unitario per quest'ultimo punto non è certamente un problema. Tuttavia, il resto del metodo è opaco a qualsiasi chiamante (inclusi i test di unità), ovvero non può essere (unità) testato a fondo . La rottura di tutti questi punti elenco nei loro metodi distinti ti consentirà di testarli.
2. Più facile da leggere
Alcune o anche tutte le attività eseguite richiedono le proprie variabili, la propria logica e i propri commenti, che devono essere scansionati e "organizzati" da un lettore.
2.a. Più facile da capire
Dalla mia esperienza, più di 3 o 4 variabili in una funzione porteranno il lettore a cercarle di nuovo durante la lettura del resto del metodo, indipendentemente da quanto semplici fossero le variabili in primo luogo. Non sto dicendo che non dovresti mai usare più di 3 o 4 variabili in un metodo, ma ti consiglio di provare ad evitarlo.
Avere più metodi consente al lettore di ignorare tutte le variabili necessarie per svolgere un'attività più piccola e invece vedere le attività più piccole come un metodo che restituisce un risultato, non di più, non di meno. Questo 'libera' su capacità intellettuali che altrimenti verrebbero utilizzate per ricordare cosa una determinata variabile ha e se sarà ancora usata altrove in una funzione.
... the span of absolute judgment and the span of immediate memory
impose severe limitations on the amount of information that we are able
to receive, process, and remember. By organizing the stimulus input
simultaneously into several dimensions and successively into a sequence
of chunks, we manage to break (or at least stretch) this informational
bottleneck.
http://psychclassics.yorku.ca/Miller/
2.b. Più facile il debug
Un bug che può essere facilmente compreso è anche molto più facile da eseguire il debug, semplicemente perché è facile definire cosa esattamente non funzioni.
È la stessa cosa che distingue una buona segnalazione di bug ("Firefox si blocca all'apertura del file SVG su Win10, registri allegati") da una cattiva ("Firefox si blocca all'apertura del file") o una buona domanda SO ("JS: Eccezione non rilevata: impossibile chiamare il metodo foo della barra ") da una cattiva (" il mio sito web non funziona, si prega di risolvere ").
2.c. Più facile da riutilizzare
A volte in futuro potresti dover risolvere un problema simile a quello che stai risolvendo ora, ad esempio se hai bisogno di adattare il testo a una forma geometrica arbitraria anziché solo un'immagine (o un rettangolo, in realtà).
Molte delle attività più piccole, come la suddivisione del testo in linee e parole, la misurazione della dimensione della parola e le parole di adattamento in una forma dovranno essere nuovamente utilizzate per implementare la nuova funzione. Invece di dover rifattorizzare queste attività più piccole con un solo metodo, perché non dividerle nei loro stessi metodi adesso?
Infine, immagina quanto di questa risposta avresti già dimenticato se fosse stato scritto senza alcuna formattazione o punti elenco.