Assicurarsi che ogni classe abbia una sola responsabilità, perché?

Secondo la documentazione Microsoft, l'articolo del principio SOLID di Wikipedia o la maggior parte degli architetti IT, dobbiamo garantire che ogni classe abbia una sola responsabilità. Vorrei sapere perché, perché se tutti sembrano essere d'accordo con questa regola nessuno sembra essere d'accordo sui motivi di questa regola.

Alcuni citano una migliore manutenzione, altri dicono che fornisce test facili o rende la classe più robusta o sicura. Cosa è corretto e cosa significa in realtà? Perché migliora la manutenzione, semplifica i test o rende il codice più robusto?

Modularità. Qualsiasi linguaggio decente ti darà i mezzi per incollare pezzi di codice, ma non esiste un modo generale per rimuovere un grosso pezzo di codice senza che il programmatore esegua un intervento chirurgico sulla fonte. Inserendo molte attività in un costrutto di codice, rubi a te stesso e agli altri l'opportunità di combinare i suoi pezzi in altri modi e introducete dipendenze non necessarie che potrebbero causare modifiche a un pezzo per influenzare gli altri.

L'SRP è applicabile tanto alle funzioni quanto alle classi, ma i linguaggi OOP tradizionali sono relativamente scarsi nell'incollare insieme le funzioni.

Una migliore manutenzione, test facili, una correzione più rapida dei bug sono solo (molto piacevoli) risultati dell'applicazione di SRP. Il motivo principale (come dice Robert C. Matin) è:

Una classe dovrebbe avere una, e una sola, ragione per cambiare.

In altre parole, SRP aumenta la località di cambiamento .

SRP promuove anche il codice DRY. Finché avremo classi che hanno una sola responsabilità, potremmo scegliere di usarle dove vogliamo. Se abbiamo una classe che ha due responsabilità, ma ne abbiamo bisogno solo una e la seconda interferisce, abbiamo 2 opzioni:

1. Copia e incolla la classe in un'altra e magari crea un altro mutante multi-responsabilità (aumenta un po 'il debito tecnico).
2. Dividi la classe e rendila come dovrebbe essere, in primo luogo, il che può essere costoso a causa dell'uso estensivo della classe originale.

È facile creare codice per risolvere un problema particolare. È più complicato creare codice che risolva quel problema, consentendo nel contempo di apportare modifiche successive in modo sicuro. SOLID fornisce una serie di pratiche che migliorano il codice.

Per quanto riguarda quello corretto: Tutti e tre. Sono tutti vantaggi dell'utilizzo della responsabilità singola e del motivo per cui è necessario utilizzarla.

Quanto a ciò che significano:

• Una migliore manutenzione significa che è più facile da cambiare e non cambia così spesso. Perché c'è meno codice e quel codice è focalizzato su qualcosa di specifico, se devi cambiare qualcosa che non è correlato alla classe, la classe non ha bisogno di essere cambiata. Inoltre, quando è necessario modificare la classe, purché non sia necessario modificare l'interfaccia pubblica, è sufficiente preoccuparsi di quella classe e nient'altro.
• Test facili significa meno test, meno installazione. Non ci sono tante parti mobili sulla classe, quindi il numero di possibili guasti sulla classe è più piccolo, e quindi meno casi che è necessario testare. Ci saranno meno membri / campi privati ​​da configurare.
• A causa delle due sopra ottenete una classe che cambia di meno e fallisce di meno, e quindi è più robusta.

Prova a creare il codice per un po 'seguendo il principio e rivedi quel codice in seguito per apportare alcune modifiche. Vedrai l'enorme vantaggio che offre.

Fai lo stesso per ogni classe e finisci con più classi, tutte conformi a SRP. Rende la struttura più complessa dal punto di vista delle connessioni, ma la semplicità di ogni classe la giustifica.

Ecco gli argomenti che, a mio avviso, supportano l'affermazione secondo cui il principio della responsabilità singola è una buona pratica. Fornisco anche collegamenti ad ulteriore letteratura, dove puoi leggere ragionamenti ancora più dettagliati - e più eloquenti dei miei:

• Migliore manutenzione : idealmente, ogni volta che una funzionalità del sistema deve cambiare, ci sarà una e una sola classe che deve essere cambiata. Una chiara mappatura tra classi e responsabilità significa che qualsiasi sviluppatore coinvolto nel progetto può identificare di quale classe si tratta. (Come ha notato @MaciejChałapuk, vedi Robert C. Martin, "Codice pulito" .)

• Test più semplici : idealmente, le classi dovrebbero avere un'interfaccia pubblica minima, e i test dovrebbero riguardare solo questa interfaccia pubblica. Se non riesci a testare con chiarezza, poiché molte parti della tua classe sono private, questo è un chiaro segno che la tua classe ha troppe responsabilità e che dovresti dividerla in sottoclassi più piccole. Si noti che ciò vale anche per le lingue in cui non vi sono membri della classe "pubblici" o "privati"; avere una piccola interfaccia pubblica significa che è molto chiaro al codice client quali parti della classe dovrebbe usare. (Vedi Kent Beck, "Test-Driven Development" per maggiori dettagli.)

• Codice robusto : il tuo codice non fallirà più o meno spesso perché è ben scritto; ma, come tutto il codice, il suo obiettivo finale non è comunicare con la macchina , ma con altri sviluppatori (vedi Kent Beck, "Schemi di implementazione" , Capitolo 1.) È più facile ragionare su una base di codice chiara, quindi verranno introdotti meno bug e passerà meno tempo tra scoprire un bug e risolverlo.

Ci sono una serie di ragioni, ma quella che mi piace è l'approccio utilizzato da molti dei primi programmi UNIX: fare bene una cosa. È abbastanza difficile farlo con una cosa, e aumentando le difficoltà, più cose provi a fare.

Un altro motivo è limitare e controllare gli effetti collaterali. Ho adorato il mio apriporta combinato per caffettiera. Sfortunatamente, il caffè di solito traboccava quando avevo visitatori. Ho dimenticato di chiudere la porta dopo aver fatto il caffè l'altro giorno e qualcuno l'ha rubato.

Dal punto di vista psicologico, puoi solo tenere traccia di alcune cose alla volta. Le stime generali sono sette più o meno due. Se una classe fa più cose, devi tenerne traccia tutte in una volta. Ciò riduce la tua capacità di tracciare ciò che stai facendo. Se una classe fa tre cose e ne vuoi solo una, puoi esaurire la tua capacità di tenere traccia delle cose prima di fare qualsiasi cosa con la classe.

Fare più cose aumenta la complessità del codice. Oltre il codice più semplice, la crescente complessità aumenta la probabilità di bug. Da questo punto di vista vuoi che le classi siano il più semplici possibile.

Testare una classe che fa una cosa è molto più semplice. Non è necessario verificare che la seconda cosa che la classe ha fatto o meno per ogni test. Inoltre, non è necessario correggere le condizioni interrotte e ripetere il test quando uno di questi test ha esito negativo.

Perché il software è organico. I requisiti cambiano costantemente, quindi è necessario manipolare i componenti con il minor mal di testa possibile. Non seguendo i principi SOLID, si potrebbe finire con una base di codice che è impostata in concreto.

Immagina una casa con un muro di cemento portante. Cosa succede quando togli questo muro senza alcun supporto? La casa probabilmente crollerà. Nel software non lo vogliamo, quindi strutturiamo le applicazioni in modo tale da poter spostare / sostituire / modificare facilmente i componenti senza causare molti danni.

Seguo il pensiero: 1 Class = 1 Job.

Usando un'analogia di fisiologia: motore (sistema neurale), respirazione (polmoni), digestivo (stomaco), olfattivo (osservazione), ecc. Ognuno di questi avrà un sottoinsieme di controller, ma ognuno di essi ha solo 1 responsabilità, sia che sia da gestire il modo in cui ciascuno dei rispettivi sottosistemi funziona o se si tratta di un sottosistema endpoint e svolgono solo 1 attività, come sollevare un dito o far crescere un follicolo pilifero.

Non confondere il fatto che potrebbe agire come manager anziché come lavoratore. Alcuni lavoratori alla fine vengono promossi a Manager, quando il lavoro che stavano eseguendo è diventato troppo complicato per un processo da gestire da solo.

La parte più complicata di ciò che ho sperimentato è sapere quando designare una Classe come processo Operatore, Supervisore o Manager. Indipendentemente da ciò, dovrai osservare e denotare la sua funzionalità per 1 responsabilità (Operatore, Supervisore o Manager).

Quando una Classe / Oggetto svolge più di 1 di questi ruoli di tipo, scoprirai che il processo generale inizierà ad avere problemi di prestazioni o elaborerà il collo di bottiglia.

Soprattutto con un principio così importante come la responsabilità singola, mi aspetterei personalmente che ci siano molte ragioni per cui le persone adottano questo principio.

Alcuni di questi motivi potrebbero essere:

• Manutenzione: SRP garantisce che la modifica della responsabilità in una classe non influisca su altre responsabilità, semplificando la manutenzione. Questo perché se ogni classe ha una sola responsabilità, le modifiche apportate a una responsabilità sono isolate dalle altre responsabilità.
• Test - Se una classe ha una responsabilità, è molto più facile capire come testare questa responsabilità. Se una classe ha più responsabilità, devi assicurarti di testare quella corretta e che il test non sia influenzato da altre responsabilità della classe.

Si noti inoltre che SRP viene fornito con un pacchetto di principi SOLID. Rispettare SRP e ignorare il resto è altrettanto male che non fare SRP in primo luogo. Quindi non dovresti valutare SRP da solo, ma nel contesto di tutti i principi SOLID.

Il modo migliore per comprendere l'importanza di questi principi è di averne bisogno.

Quando ero un programmatore alle prime armi, non pensavo molto al design, infatti, non sapevo nemmeno che esistessero modelli di design. Man mano che i miei programmi crescevano, cambiare una cosa significava cambiare molte altre cose. È stato difficile rintracciare i bug, il codice era enorme e ripetitivo. Non c'era molto di una gerarchia di oggetti, le cose erano dappertutto. L'aggiunta di qualcosa di nuovo o la rimozione di qualcosa di vecchio porterebbe errori nelle altre parti del programma. Vai a capire.

Sui piccoli progetti, potrebbe non avere importanza, ma nei grandi progetti, le cose possono essere molto da incubo. Più tardi, quando mi sono imbattuto nei concetti di schemi di design, mi sono detto: "oh sì, fare questo avrebbe reso le cose molto più facili allora".

Non puoi davvero capire l'importanza dei modelli di progettazione fino a quando non sorge la necessità. Rispetto i modelli perché per esperienza posso dire che rendono la manutenzione del codice semplice e robusta.

Tuttavia, proprio come te, sono ancora incerto sul "test facile", perché non ho ancora avuto la necessità di entrare in test unitari.

La risposta è, come altri hanno sottolineato, tutti sono corretti e si alimentano a vicenda, più facile da testare rende più facile la manutenzione rende il codice più robusto rende la manutenzione più semplice e così via ...

Tutto ciò si riduce a un principio chiave: il codice dovrebbe essere piccolo e fare il minimo necessario per portare a termine il lavoro. Questo vale per un'applicazione, un file o una classe tanto quanto una funzione. Più cose fa un pezzo di codice, più difficile è capire, mantenere, estendere o testare.

Penso che si possa riassumere in una parola: portata. Presta molta attenzione all'ambito dei manufatti, minore è il campo di applicazione in un determinato punto in un'applicazione, meglio è.

Portata estesa = più complessità = più modi in cui le cose vanno male.

Se una classe è troppo grande, diventa difficile mantenere, testare e capire, altre risposte hanno coperto questa volontà.

È possibile che una classe abbia più di una responsabilità senza problemi, ma presto si verificano problemi con classi troppo complesse.

Tuttavia, avere una semplice regola di "una sola responsabilità" rende più semplice sapere quando è necessaria una nuova classe .

Tuttavia, definire la "responsabilità" è difficile, non significa "fare tutto quello che dice la specifica dell'applicazione", la vera abilità è sapere come scomporre il problema in piccole unità di "responsabilità".