Con questa conoscenza limitata del tuo programma, in questo momento il mio consiglio è di lasciare quelle 3 righe da solo.
Il problema è che stai descrivendo il problema strutturalmente. Qualche programma ... Fine di qualche metodo ... tre linee ... Non c'è storia qui. Nessun contesto in cui vivere questa idea.
Stai tentando di inserire un'idea nella tua struttura strutturata di pensiero sul codice ed è sconcertante. Il concetto di "fare una cosa" non ha senso quando puoi riempire letteralmente l'intero programma in una sola cosa.
Questa regola non riguarda la struttura. Si tratta di idee. Potresti insistere sul fatto che un oritteropo in sella a una bicicletta è una cosa, ma è una cosa dannatamente strana. Un oritteropo a parte e una bicicletta a parte sono meno strani, quindi sono contro la classe AardvarkBicycle .
Se ciò sembra insoddisfacente perché è soggettivo, dico troppo male. Stiamo progettando un software che gli esseri umani possano comprendere, quindi ci si abitua a gestire il nostro strano pregiudizio umano.
Nel suo ultimo libro Clean Architecture Uncle Bob ridefinisce il Principio di Responsabilità Unica, quando applicato specificamente alle classi, nel contesto di chi è responsabile del codice. Nessuna classe può servire a due padroni. Questa è una considerazione eccellente, ma sei pazzo se è il tuo unico. In questa prospettiva, teoricamente, sarebbe opportuno identificare tutti i soggetti interessati e dare a ciascuno la propria classe e interrompere la decomposizione proprio lì. Bleh. Questo non è quello che dice lo zio Bob.
Se insisti a pensare strutturalmente, la miglior ragione per scegliere una classe rispetto a una funzione è perché ci sono alcuni dati persistenti che vuoi usare per cambiare il tuo comportamento. Alcuni dati che impari in un momento diverso da quello in cui mostri il tuo comportamento. Ora, se hai solo un comportamento, una chiusura potrebbe essere abbastanza buona, se la tua lingua ha questo. Se si hanno due comportamenti che devono variare in base a questi stessi dati, si è fermamente nella terra degli oggetti. Gli oggetti sono sacchetti di funzioni che cambiano il loro comportamento insieme
Se vi unirete a me anche pensando semanticamente, non solo strutturalmente, troverete che ha senso estrarre qualcosa come classe se si può pensare ad un buon nome che assicura quando qualcuno guarda dentro e vede i dettagli trovare più o meno quello che si aspettavano. Se hai sorpresa hai fallito. Per le funzioni è la stessa storia, solo con un verbo. In entrambi i casi il termine di fantasia per questo è l'astrazione.
E non pensare che non ti ho notato usando nomi come verbi nel titolo della domanda: P
Se ritieni ancora necessario estrarre questo codice, ti consigliamo di leggere su il buco nel modello centrale