Il principio di responsabilità singola è applicabile alle funzioni?

Secondo Robert C. Martin, l'SRP afferma che:

Non ci dovrebbe mai essere più di un motivo per cambiare una classe .

Tuttavia, nel suo libro Clean Code , capitolo 3: Funzioni, mostra il seguente blocco di codice:

    public Money calculatePay(Employee e) throws InvalidEmployeeType {
        switch (e.type) {
            case COMMISSIONED:
                return calculateCommissionedPay(e);
            case HOURLY:
                return calculateHourlyPay(e);
            case SALARIED:
                return calculateSalariedPay(e);
            default:
                throw new InvalidEmployeeType(e.type);
        }
    }

E poi afferma:

Esistono diversi problemi con questa funzione. Innanzitutto, è grande e quando vengono aggiunti nuovi tipi di dipendenti, crescerà. In secondo luogo, fa chiaramente più di una cosa. In terzo luogo, viola il principio di responsabilità singola (SRP) perché esiste più di una ragione per cambiare . [enfasi mia]

In primo luogo, ho pensato che l'SRP fosse definito per le classi, ma si scopre che è applicabile anche alle funzioni. In secondo luogo, in che modo questa funzione ha più di un motivo per cambiare ? Posso solo vederlo cambiare a causa di un cambiamento sul Dipendente.

Un dettaglio spesso mancato del Principio della singola responsabilità è che i "motivi del cambiamento" sono raggruppati per attori del caso d'uso (puoi vedere una spiegazione completa qui ).

Quindi, nel tuo esempio, il calculatePaymetodo dovrà essere modificato ogni volta che sono richiesti nuovi tipi di dipendenti. Poiché un tipo di dipendente potrebbe non avere nulla a che fare con un altro, sarebbe una violazione del principio se li tenessi insieme, poiché la modifica interesserebbe diversi gruppi di utenti (o attori del caso d'uso) nel sistema.

Ora, se il principio si applica alle funzioni: anche se hai una violazione in un solo metodo, stai ancora cambiando una classe per più di un motivo, quindi è ancora una violazione di SRP.

A pagina 176, Capitolo 12: Emergenza, nella sezione Classi e metodi minimi il libro fornisce in qualche modo una correzione, affermando:

Nel tentativo di ridurre le nostre classi e metodi, potremmo creare troppe piccole classi e metodi. Quindi questa regola suggerisce che manteniamo bassi anche i nostri conteggi di funzioni e classi

e

Conteggi di classe e metodi elevati sono talvolta il risultato di un dogmatismo inutile.

Ovviamente, sta parlando di dogmatismo nel seguire la SRP per abbattere perfettamente piccoli metodi innocenti come calculatePay()sopra.

Quando il signor Martin applica l'SRP a una funzione, sta implicitamente estendendo la sua definizione di SRP. Poiché l'SRP è una formulazione specifica di OO di un principio generale, e poiché è una buona idea quando applicata alle funzioni, non vedo alcun problema con quello (anche se potrebbe essere bello se lo avesse incluso esplicitamente nel definizione).

Non vedo più di una ragione per cambiare, e non credo che pensare all'SRP in termini di "responsabilità" o "ragioni per cambiare" sia utile. In sostanza, l'SRP sta ottenendo che le entità software (funzioni, classi, ecc.) Dovrebbero fare una cosa e farlo bene.

Se dai un'occhiata alla mia definizione, non è meno vago della solita formulazione dell'SRP. Il problema con le normali definizioni dell'SRP non è che sono troppo vaghe, ma che cercano di essere troppo specifiche su qualcosa che è essenzialmente vago.

Se guardi cosa calculatePayfa, sta chiaramente facendo una cosa sola: spedire in base al tipo. Dal momento che Java ha dei modi integrati per eseguire la spedizione basata sul tipo, calculatePayè inelegante e non idiomatico, quindi dovrebbe essere riscritto, ma non per i motivi dichiarati.

Hai ragione @Enrique. Non importa se è una funzione o un metodo di una classe, l'SRP significa che in quel blocco di codice fai solo una cosa.

L'affermazione "motivo per cambiare" a volte è un po 'fuorviante, ma se cambi calculateSalariedPayo calculateHourlyPayo l'enum di Employee.typete devi cambiare questo metodo.

Nel tuo esempio la funzione:

• controlla il tipo di dipendente
• chiama un'altra funzione che calcola il denaro in base al tipo

Secondo me non è direttamente una violazione di SRP, poiché i casi di cambio e le chiamate non possono essere scritti più brevi, se si pensa al Dipendente e i metodi esistono già. Comunque è una chiara violazione del principio aperto-chiuso (OCP) in quanto è necessario aggiungere dichiarazioni "case" se si aggiungono tipi di dipendenti, quindi è una cattiva implementazione: rifattorizzarla.

Non sappiamo come calcolare il "denaro", ma il modo più semplice è avere Employeecome interfaccia e alcune implementazioni concrete con i getMoneymetodi. In tal caso, l'intera funzione è inutile.

Se è più complicato calcolarlo, si potrebbe usare il modello visitatore che non è anche SRP al 100% ma è più OCP di un caso di switch.