Was ist ein Beispiel für das Prinzip der einheitlichen Verantwortung?

Question

Kann mir jemand ein Beispiel für das Prinzip der einfachen Verantwortlichkeit geben? Ich versuche zu verstehen, was es in der Praxis bedeutet, dass eine Klasse eine einzige Verantwortung trägt, da ich befürchte, dass ich diese Regel wahrscheinlich täglich brechen werde.

Answer 1

Überprüfen Sie die Solid description.

Wenn Sie nicht nach etwas spezifischerem fragen, wird es schwer sein, mehr zu helfen.

Eine einzige Verantwortlichkeit ist das Konzept einer Klasse, die eine bestimmte Sache (Verantwortung) macht und nicht versucht, mehr zu tun, als es sollte, was auch als hohe Kohäsion bezeichnet wird.

Klassen beginnen oft nicht mit Low Cohesion, aber in der Regel nach mehreren Releases und verschiedenen Entwicklern, die sie hinzufügen, werden Sie plötzlich bemerken, dass es ein Monster oder eine Gottklasse wurde, wie einige es nennen. Also sollte die Klasse refaktoriert werden.

Es ist schwer, an ein gutes Beispiel zu denken, aber eines, das ich vor kurzem denken könnte, wäre eine Klasse, die verschiedene Paketverarbeitungsstufen verwaltet, eine Art von Chain of Responsibility. Die ursprüngliche Absicht dieser Klasse bestand darin, eine Liste von Stufen aufrechtzuerhalten und das Aufrufen von packetProcess() für sie zu orchestrieren. Nun, es endete damit, dass jeder etwas mit den Verarbeitungsstufen (da die Manager-Klasse ein einfacher Ort war, um auf die Stufen zuzugreifen) zu dieser Manager-Klasse, insbesondere der Bühnenkonfiguration, hinzukam. Die Manager-Klasse hatte keine Einzelverantwortlichkeit mehr, sondern war auch dafür verantwortlich, Aufrufe zu den Stufen für Konfigurationsänderungen zu tätigen: So war der Zusammenhalt reduziert.

Am Ende mussten wir die Manager-Klasse umgestalten, die gesamte Bühnenkonfiguration ausradieren und in eine Fabrik stellen, so dass der Manager das tun konnte, was er vorhatte.

Answer 2

Der effektivste Weg, um Anwendungen zu brechen, um Klassen zu erstellen. Das sind Klassen, die viele Informationen verfolgen und mehrere Verantwortlichkeiten haben. Eine Codeänderung wird höchstwahrscheinlich andere Teile der Klasse und daher indirekt alle anderen Klassen betreffen, die sie verwenden. Dies wiederum führt zu einem noch größeren Wartungsaufwand, da niemand etwas anderes zu ändern wagt, als neue Funktionen hinzuzufügen.

Das folgende Beispiel ist ein Typoskript Klasse, die eine Person, diese Klasse gehören sollten keine E-Mail-Validierung definiert, weil das nicht mit einer Person Verhalten zusammenhängt:

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!"); 
    } 
} 

Wir verbessern die Klasse oben durch Entfernen die Verantwortung der E-Mail-Validierung von der Person-Klasse und eine neue E-Mail-Klasse erstellen, die die Verantwortung haben:

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!"); 
    } 
} 

sicherzustellen, dass eine Klasse eine einzelne respon hat Dadurch wird es auch einfacher zu sehen, was es tut und wie Sie es erweitern/verbessern können.

Answer 3

Prinzip der einheitlichen Verantwortung (Single Responsibility Principle, SRP) besagt, dass eine Klasse oder eine Methode nur eine Sache tun sollte und nichts damit zu tun haben sollte. Eine Klasse sollte nur einen Grund haben, sich zu ändern.

Ein typisches Beispiel eine EmailSender Klasse könnte:

• dies sollte nur austeilen eine E-Mail mit dem Senden.
• sollte dies nicht für das Laden der E-Mail-Inhalte aus der Datenbank oder auch die Formatierung der E-Mail-Inhalte gesendet werden sollen verantwortlich sein.

Here ist ein Artikel zu diesem Thema.

Answer 4

sollte eine Klasse nur einen Grund zu ändern.

Dieses Prinzip besagt, dass, wenn wir zwei Gründe für eine Klasse zu ändern, müssen wir die Funktionalität in zwei Klassen aufgeteilt. Jede Klasse wird nur eine Verantwortung übernehmen und wenn wir in der Zukunft eine Änderung vornehmen müssen, werden wir es in der Klasse machen, die es behandelt.

Wenn es zwei verschiedene Gründe zu ändern, ist es denkbar, dass zwei verschiedene Teams aus zwei verschiedenen Gründen auf dem gleichen Code arbeiten können. Jeder muss seine Lösung bereitstellen, was im Fall einer kompilierten Sprache (wie C++, C# oder Java) zu inkompatiblen Modulen mit anderen Teams oder anderen Teilen der Anwendung führen kann.

Dieses Prinzip ist eng mit den Konzepten der Kopplung und Kohäsion im Zusammenhang. Kopplung bezieht sich darauf, wie untrennbar verschiedene Aspekte einer Anwendung verknüpft sind, während Kohäsion darauf verweist, wie eng der Inhalt einer bestimmten Klasse oder eines Pakets zusammenhängt. Alle Inhalte einer einzelnen Klasse sind eng miteinander verbunden, da die Klasse selbst eine [einzelne Einheit] [1] ist, die entweder vollständig oder gar nicht verwendet werden muss.

Mein Blog-Eintrag dazu:

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