Perché la coesione sequenziale per le operazioni in un metodo non è una buona idea?

Question

Ho letto dal seminale Codice libro completo Quelle dichiarazioni del metodo che richiedono di essere eseguite per il passaggio del parametro da uno a quella successiva sono un odore di codice ed è un esempio di a coesione sequenziale. Perché questa non è una buona idea?

Un esempio inventato di una coesione sequenziale:

public Part createPart(input) {
        PartOne partOne = computePartOne(input);
        PartTwo partTwo = computePartTwo(partOne);
        PartThree partThree = computePartThree(partTwo);
        PartsBuilder partsBuilder = new PartsBuilder();
        return partsBuilder.add(partOne).add(partTwo).add(partThree).build();
    }

Ecco l'esercizio:

Diversi altri tipi di coesione sono normalmente considerati meno che ideali:

Coesione sequenziale esiste quando una routine contiene operazioni che devono essere eseguite in un ordine specifico, che condividono i dati da un passo all'altro e che non costituiscono una funzione completa quando fatta insieme.

Un esempio di coesione sequenziale è una routine che, data una data di nascita, calcola l'età e il tempo di un dipendente. Se la routine calcola l'età e quindi usa quel risultato per calcolare il tempo del dipendente alla pensione, ha una coesione sequenziale. Se la routine calcola l'età e quindi calcola il tempo alla pensione in un calcolo completamente separato che sembra utilizzare gli stessi dati della data di nascita, ha solo una coesione comunicativa.

Come renderesti la routine funzionalmente coerente? Creeresti routine separate per calcolare l'età di un dipendente, data una data di nascita e calcolare il tempo alla pensione data una data di nascita. La routine tempo-per pensionamento potrebbe chiamare la routine di età. Avrebbero entrambi coesione funzionale. Altre routine potrebbero chiamare la routine o entrambe le routine.