it-swarm.com.de

Was ist ein Beispiel für das Prinzip der Einzelverantwortung?

Kann mir jemand ein Beispiel für das Prinzip der einheitlichen Verantwortung 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 täglich gegen diese Regel verstoße.

27
Sachin Kainth

Schauen Sie sich die Solid Beschreibung an. 

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

Einzelverantwortung ist das Konzept einer Klasse, die eine bestimmte Sache (Verantwortung) tut und nicht versucht, mehr zu tun, als sie sollte, was auch als "hohe Kohäsion" bezeichnet wird.

Klassen beginnen nicht oft mit Low Cohesion, aber normalerweise, nachdem mehrere Releases und verschiedene Entwickler sie hinzugefügt haben, merkt man plötzlich, dass es ein Monster oder eine Gott-Klasse geworden ist, wie manche es nennen. Die Klasse sollte also umgestaltet werden.

Es ist schwer, sich ein gutes Beispiel vorzustellen, aber in letzter Zeit könnte ich mir vorstellen, dass eine Klasse, die verschiedene Paketverarbeitungsstufen verwaltet, ein Typ von Chain of Responsibility ist. Die ursprüngliche Absicht dieser Klasse war es, eine Liste von Stufen zu pflegen und den Aufruf von packetProcess () für sie zu orchestrieren. Nun, es endete, dass jeder etwas zu den Verarbeitungsstufen hinzufügte (da die Manager-Klasse ein einfacher Ort für den Zugriff auf die Stufen war), zu dieser Manager-Klasse, insbesondere zur Bühnenkonfiguration. Die Manager-Klasse hatte keine Einzelverantwortung mehr, sondern war auch dafür verantwortlich, Aufrufe für Konfigurationsänderungen zu fordern: Der Zusammenhalt war also reduziert worden.

Am Ende mussten wir die Manager-Klasse umgestalten, die gesamte Bühnenkonfiguration herausnehmen und in eine Fabrik bringen, sodass der Manager das tun konnte, was er beabsichtigte.

4
Brady

Der effektivste Weg, um Anwendungen zu unterbrechen, um GOD Klassen zu erstellen. Das sind Klassen, die viele Informationen nachverfolgen und verschiedene Verantwortlichkeiten haben. Eine Codeänderung wirkt sich höchstwahrscheinlich auf andere Teile der Klasse aus und daher indirekt auf alle anderen Klassen, die sie verwenden. Dies führt wiederum zu einem noch größeren Wartungs-Chaos, da niemand mehr Änderungen an dieser Stelle wagt, als neue Funktionen hinzuzufügen.

Das folgende Beispiel ist eine TypeScript-Klasse, die eine Person definiert. Diese Klasse sollte keine E-Mail-Überprüfung enthalten, da dies nicht mit einem Personenverhalten 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 können die Klasse oben verbessern, indem wir die Verantwortung für die E-Mail-Validierung aus der Person-Klasse entfernen und eine neue Email-Klasse erstellen, die diese Verantwortung trägt:

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

Wenn Sie sicherstellen, dass eine Klasse eine einzige Verantwortung hat, wird standardmäßig auch leichter ersichtlich, was sie tut und wie Sie sie erweitern/verbessern können.

32
Remo H. Jansen

Das Prinzip der einfachen Verantwortung (Single Responsibility Principle, SRP) besagt, dass eine Klasse oder eine Methode nur eine Sache tun sollte und nichts damit zusammenhängendes tun sollte. Eine Klasse sollte nur einen Grund zum Ändern haben.

Ein typisches Beispiel könnte eine EmailSender-Klasse sein:

  • dies sollte nur das Versenden einer E-Mail betreffen.
  • dies sollte nicht dafür verantwortlich sein, den E-Mail-Inhalt aus der Datenbank zu laden oder sogar den zu sendenden E-Mail-Inhalt zu formatieren.

Hier ist ein Artikel dazu.

2
Ranganatha

Eine Klasse sollte nur einen Grund zum Ändern haben.

Dieses Prinzip besagt, dass, wenn wir zwei Gründe für eine Änderung haben, die Funktionalität in zwei Klassen aufgeteilt werden muss. Jede Klasse wird nur mit einer Verantwortung umgehen, und wenn wir in der Zukunft eine Änderung vornehmen müssen, werden wir sie in der Klasse vornehmen, die sie behandelt.

Wenn es zwei verschiedene Gründe für eine Änderung gibt, ist es denkbar, dass zwei verschiedene Teams aus zwei verschiedenen Gründen mit demselben Code arbeiten können. Jeder muss seine Lösung implementieren, was bei einer kompilierten Sprache (wie C++, C # oder Java) zu inkompatiblen Modulen mit anderen Teams oder anderen Teilen der Anwendung führen kann.

Dieses Prinzip steht in engem Zusammenhang mit den Konzepten von Kopplung und Zusammenhalt. Kopplung bezieht sich darauf, wie untrennbar unterschiedliche Aspekte einer Anwendung miteinander verbunden sind, während Kohäsion darauf bezieht, wie eng der Inhalt einer bestimmten Klasse oder eines bestimmten Pakets in Beziehung steht. 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 Blogeintrag dazu:

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

1
Rajesh Dixit