Passa lo stesso argomento a più piccole funzioni rispetto a fare tutto in un'unica grande funzione?

Question

Passa lo stesso argomento a più piccole funzioni rispetto a fare tutto in un'unica grande funzione?

#1 da (2 voti)

0

Ho ereditato un metodo di classe da un altro sviluppatore, che ha il seguente aspetto: (Nota: Class:X significa X è un membro di Class nel paradigma OOP.)

Class:BigFunction() 
{
    ImportantValue = calculateImportantValue()

    Iterate over Class:Foo from 1 to ImportantValue
    Iterate over Class:Bar from 1 to ImportantValue
    Iterate over Class:Baz from 1 to ImportantValue

    # ... and so on ...
}

Sto prendendo in considerazione il refactoring di qualcosa del tipo:

Class:WrapSeveralSmallFunctions() 
{
    ImportantValue = calculateImportantValue()

    IterateFoo(ImportantValue)
    IterateBar(ImportantValue)
    IterateBaz(ImportantValue)

    # ... and so on ...
}

Class:IterateFoo(ImportantValue)
{
    Iterate over Foo from 1 to ImportantValue
}

Class:IterateBar(ImportantValue)
{
    Iterate over Bar from 1 to ImportantValue
}

Class:IterateBaz(ImportantValue)
{
    Iterate over Baz from 1 to ImportantValue
}

Per principio di singola responsabilità, il codice refactored mi sembra migliore.

Tuttavia, sono anche preoccupato di passare ImportantValue come argomento per ogni funzione "piccola". La mia preoccupazione è valida? Il refactoring proposto è considerato una buona pratica di codifica o esiste un modo migliore per scrivere questo codice?

object-oriented language-agnostic code-quality refactoring

posta Masked Man 28.05.2015 - 06:35

fonte

1 risposta

Leggi altre domande sui tag object-oriented language-agnostic code-quality refactoring

Quando si distribuisce un'app di produzione utilizzando la finestra mobile, dovrei comunque utilizzare i volumi o dovrei usare add in dockerfile? Come acquisire dati e pagina di rendering nel contesto dell'applicazione REST / API?

score 2 · Accepted Answer

In termini di prestazioni, non ci sarà praticamente alcuna differenza tra le due opzioni considerate.

In teoria, il Principio della singola responsabilità suggerisce che la soluzione con diverse piccole funzioni chiamate da quella grande sia preferibile se le piccole funzioni hanno senso . Ci sono semanticamente ben definiti? Quando leggi i nomi delle funzioni e i cicli for nel flusso di esecuzione, leggi una storia coerente?

Se, considerate individualmente, le piccole funzioni non hanno un obiettivo chiaro e ben definito, il refactoring è probabilmente troppo fine e controproducente. A seconda del tuo linguaggio di programmazione, puoi prendere in considerazione l'utilizzo della codifica avanzata degli elenchi o dello stile funzionale per ridurre la verbosità.

Ad esempio, il seguente codice limita la gestione di ogni raccolta a una singola riga, che è tanto semplice da comprendere come una chiamata a una piccola funzione con un ciclo for.

Class:BigFunction()
{
    ImportantValue = calculateImportantValue()

    Class:Foo.take(ImportantValue).foreach(f => apply(f))
    Class:Bar.take(ImportantValue).foreach(f => apply(f))
    Class:Baz.take(ImportantValue).foreach(f => apply(f))
}

Se devi sistematicamente elaborare i tuoi tre elenchi in più funzioni "grandi", può essere una prova che la classe stessa viola l'SRP. Pertanto, dovresti considerare di dividere la classe. Questa operazione è anche un refactoring.