Qual è un esempio del principio di responsabilità singola?

Question

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

Answer 1

Verificare il Solid description.

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

La singola responsabilità è il concetto di una classe 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 Coesione bassa, ma in genere dopo diverse versioni e diversi sviluppatori che si aggiungono a esse, improvvisamente noterete che è diventato un mostro o una classe di Dio come alcuni chiamano. Quindi la classe dovrebbe essere refactored.

È difficile pensare a un buon esempio, ma quello che posso pensare di recente sarebbe una classe che abbiamo che gestisce diverse fasi di elaborazione dei pacchetti, un tipo di Chain of Responsibility. L'intenzione iniziale di questa classe 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 classe manager era un posto facile per accedere alle fasi) a questa classe manager, in particolare la configurazione dello stage. La classe 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 classe manager, la creazione di tutte le configurazioni di stage e la sua messa in una fabbrica, lasciando quindi il gestore a fare ciò che era destinato a fare.

Answer 2

Il modo più efficace per rompere le applicazioni per creare GOD classi. Quelle sono classi che tengono traccia di molte informazioni e hanno diverse responsabilità. Una modifica del codice molto probabilmente interesserà altre parti della classe 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 che segue è una classe dattiloscritto che definisce una persona, questa classe non dovrebbe includere la convalida e-mail perché non è in relazione con un comportamento 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})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i; 
     return re.test(email); 
    } 
    greet() { 
     alert("Hi!"); 
    } 
} 

Siamo in grado di migliorare la classe superiore, eliminando la responsabilità di convalida e-mail dalla classe persona e la creazione di una nuova classe e-mail 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})\.([a-z]{2,6}(?:\.[a-z]{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 classe ha un unico respon la sua sensibilità rende per impostazione predefinita anche più facile vedere cosa fa e come è possibile estenderlo/migliorarlo.

Answer 3

Responsabilità unico principio (SRP) afferma che una classe o di un metodo dovrebbe fare una sola cosa e non dovrebbe essere alcun facendo relativi nulla. Una classe dovrebbe avere solo una ragione per cambiare.

Un esempio tipico potrebbe una classe EmailSender:

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

Here è un articolo su questo.

Answer 4

Una classe dovrebbe avere solo un motivo per cambiare.

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

Se ci sono due diversi motivi per cambiare, è ipotizzabile che due team diversi 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 classe o pacchetto. Tutti i contenuti di una singola classe sono strettamente accoppiati, poiché la classe stessa è una [singola unità] [1] che deve essere interamente utilizzata o non essere affatto utilizzata.

Il mio blog post su questo:

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