Qual è un esempio del principio di responsabilità unica?

Qualcuno può darmi un esempio del Principio di Responsabilità Unica? Sto cercando di capire cosa significa, in pratica, che una class abbia una singola responsabilità, poiché temo di infrangere questa regola ogni giorno.

Controlla la descrizione Solid .

A meno che tu non chieda qualcosa di più specifico, sarà difficile aiutare di più.

La singola responsabilità è il concetto di una class che fa una cosa specifica (responsabilità) e non cerca di fare più di quanto dovrebbe, che è anche nota come alta coesione.

Le classi spesso non iniziano con la bassa coesione, ma in genere dopo diverse versioni e diversi sviluppatori che si aggiungono a loro, improvvisamente noterai che è diventato un mostro o una class di Dio come alcuni chiamano. Quindi la class dovrebbe essere refactored.

È difficile pensare ad un buon esempio, ma quello che posso pensare di recente sarebbe una class che abbiamo che gestisce diverse fasi di elaborazione dei pacchetti, un tipo di Chain of Responsibility . L’intenzione iniziale di questa class era di mantenere un elenco di fasi e di orchestrare il pacchetto packetProcess () su di esse. Bene, si è concluso che tutti hanno aggiunto qualcosa a che fare con le fasi di elaborazione (poiché la class manager era un posto facile per accedere alle fasi) a questa class manager, in particolare la configurazione dello stage. La class manager non aveva più una singola responsabilità, ma era anche responsabile di effettuare chiamate alle fasi per le modifiche alla configurazione: quindi la coesione era stata ridotta.

Abbiamo finito con il dover refactoring della class manager, estrapolando tutte le configurazioni del palco e inserendole in una fabbrica, lasciando così il manager a fare ciò che intendeva fare.

Il modo più efficace per interrompere le applicazioni per creare classi GOD . Sono classi che tengono traccia di molte informazioni e hanno diverse responsabilità. Una modifica del codice molto probabilmente interesserà altre parti della class e quindi indirettamente tutte le altre classi che la utilizzano. Ciò a sua volta porta a un pasticcio di manutenzione ancora più grande dal momento che nessuno osa apportare modifiche diverse dall’aggiunta di nuove funzionalità.

L’esempio seguente è una class TypeScript che definisce una Person , questa class non deve includere la convalida della posta elettronica perché non è correlata a un comportamento di una persona:

 class Person { public name : string; public surname : string; public email : string; constructor(name : string, surname : string, email : string){ this.surname = surname; this.name = name; if(this.validateEmail(email)) { this.email = email; } else { throw new Error("Invalid email!"); } } validateEmail(email : string) { var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([az]{2,6}(?:\.[az]{2})?)$/i; return re.test(email); } greet() { alert("Hi!"); } } 

Possiamo migliorare la class di cui sopra rimuovendo la responsabilità della convalida della posta elettronica dalla class Person e creando una nuova class di Email che avrà tale responsabilità:

 class Email { public email : string; constructor(email : string){ if(this.validateEmail(email)) { this.email = email; } else { throw new Error("Invalid email!"); } } validateEmail(email : string) { var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([az]{2,6}(?:\.[az]{2})?)$/i; return re.test(email); } } class Person { public name : string; public surname : string; public email : Email; constructor(name : string, surname : string, email : Email){ this.email = email; this.name = name; this.surname = surname; } greet() { alert("Hi!"); } } 

Fare in modo che una class abbia una singola responsabilità rende per impostazione predefinita anche più facile vedere cosa fa e come è ansible estenderlo / migliorarlo.

Il Principio di Responsabilità Unico (SRP) afferma che una class o un metodo dovrebbero fare solo una cosa e non dovrebbe essere nulla che faccia qualcosa relativo. Una class dovrebbe avere solo una ragione per cambiare.

Un esempio tipico potrebbe essere una class EmailSender:

  • questo dovrebbe solo trattare con l’invio di una e-mail.
  • questo non dovrebbe essere responsabile del caricamento del contenuto dell’email dal database o persino della formattazione del contenuto dell’email da inviare.

Ecco un articolo su questo.

Una class dovrebbe avere solo una ragione per cambiare.

Questo principio afferma che se abbiamo 2 motivi per cambiare per una class, dobbiamo dividere la funzionalità in due classi. Ogni class gestirà una sola responsabilità e se in futuro dovremo apportare una modifica, la faremo nella class che la gestisce.

Se ci sono due diversi motivi per cambiare, è ipotizzabile che due squadre diverse possano lavorare sullo stesso codice per due diversi motivi. Ognuno dovrà implementare la propria soluzione, che nel caso di un linguaggio compilato (come C ++, C # o Java), può portare a moduli incompatibili con altri team o altre parti dell’applicazione.

Questo principio è strettamente correlato ai concetti di accoppiamento e coesione. L’accoppiamento si riferisce al modo in cui i diversi aspetti di un’applicazione sono collegati in modo inestricabile, mentre la coesione si riferisce a quanto strettamente correlato può essere il contenuto di una particolare class o pacchetto. Tutti i contenuti di una singola class sono strettamente accoppiati, poiché la class stessa è una [singola unità] [1] che deve essere interamente utilizzata o non essere affatto utilizzata.

Il mio post sul blog su questo:

http://javaexplorer03.blogspot.in/2016/12/single-responsibility-principle.html