Prinzip der einzigen Verantwortung: Eine Klasse, nur ein Grund, der ihre Veränderung verursacht.
Warum ist das Prinzip der einzigen Verantwortung erforderlich?
Wenn eine Klasse mehrere Gründe hat, um sie zu ändern, kann das Ändern einer Funktion zu anderen Funktionen führen. Daher ist es am besten, nur eine Verantwortung für eine Klasse zu haben. In praktischen Anwendungen ist es jedoch immer noch schwierig, es zu erreichen, sodass wir nur unser Bestes geben können, um dieses Prinzip einzuhalten.
Manchmal haben Entwickler Probleme beim Entwerfen von Schnittstellen, wie z. B. die Eigenschaften des Benutzers und das Benutzerverhalten, die in einer Schnittstelle deklariert werden. Dies führt dazu, dass die Geschäftsobjekt- und Geschäftslogik zusammengestellt wird, wodurch die Schnittstelle zwei Verantwortlichkeiten aufweist. Die Schnittstellenverantwortung ist unklar und verstößt nach der Definition von SRP gegen das Prinzip der einzelnen Verantwortlichkeiten der Schnittstelle.
Hier ist ein Beispiel:
Paket com.loulijun.Kapitel1; public interface itutu {// Höhe void setshengao (doppelte Höhe); doppelt getshengao (); // Gewicht void settizhong (Doppelgewicht); doppelt gettizhong (); // boolean Chifan (boolean hungriger) essen; // im Internet Boolean Shangwang (boolean albern); }Das obige Beispiel hat dieses Problem. Größe und Gewicht gehören zum Geschäftsobjekt, und die entsprechende Methode ist hauptsächlich für die Attribute des Benutzers verantwortlich. Essen und Surfen des Internets sind die entsprechende Geschäftslogik, die hauptsächlich für das Verhalten des Benutzers verantwortlich ist. Dies wird den Menschen jedoch das Gefühl geben, dass sie nicht wissen, was diese Schnittstelle tut, die Verantwortlichkeiten sind nicht klar und verschiedene Probleme werden auch während der späteren Wartung verursacht.
Lösung: Das Prinzip der einzigen Verantwortung unterteilen diese Schnittstelle in zwei Schnittstellen mit unterschiedlichen Verantwortlichkeiten.
Itutubo.java: Verantwortlich für die Attribute von Tutu (Tutu, wenn es sich um einen persönlichen Namen handelt)
Paket com.loulijun.Kapitel1; /*** bo: Business -Objekt, Geschäftsobjekt* verantwortlich für die Attribute des Benutzers* @Author Administrator**/public interface itutubo {// Höhe void setshengao (Doppelhöhe); doppelt getshengao (); // Gewicht void settizhong (Doppelgewicht); doppelt gettizhong (); }Itutubl.java: verantwortlich für die Platzierung
Paket com.loulijun.Kapitel1; /*** BL: Business Logic, Geschäftslogik* Verantwortlich für das Benutzerverhalten* @Author Administrator**/öffentliche Schnittstelle itutubl {// einen Mahlzeiten -Boolean -Chifan (boolean hungrig); // Unterhaltung Boolean Shangwang (boolean albern); }Dies erkennt die einzige Verantwortung der Schnittstelle. Bei der Implementierung einer Schnittstelle gibt es zwei verschiedene Klassen
Tutubo.java
Paket com.loulijun.Kapitel1; öffentliche Klasse Tutubo implementiert itutubo {private doppelte Höhe; privates Doppelgewicht; @Override public double getshengao () {return height; } @Override public double gettizhong () {return Gewicht; } @Override public void setshengao (doppelte Höhe) {this.height = height; } @Override public void settiZhong (doppeltes Gewicht) {this.weight = Gewicht; }}Tutubl.java
Paket com.loulijun.Kapitel1; public class tutubl implementiert itutubl {@Override public boolean chifan (boolean hungry) {if (hungry) {System.out.println ("Gehen Sie zu Hot Pot ..."); zurückkehren; } return false; } @Override public boolean shangwang (boolean alberg) {if (alberg) {System.out.println ("So langweilig, gehen Sie ins Internet ..."); zurückkehren; } return false; }}Das macht es klar. Wenn Sie die Benutzerattribute ändern müssen, müssen Sie nur die ITUTUBO -Schnittstelle ändern, die sich nur auf die Tutubo -Klasse auswirkt und andere Klassen nicht beeinflusst.
Zusammenfassen:
1. Die tatsächliche Situation ist, dass wir die "Ursache der Veränderung" oft im Voraus nicht vorhersehen können, sodass wir unsere Schnittstelle nur basierend auf der Erfahrung erstellen und versuchen können, sicherzustellen, dass eine Schnittstelle nur eine Verantwortung hat. Was wir hier sprechen, sind Schnittstellen. Klassen können mehrere Schnittstellen erben und implementieren, was es schwieriger macht, eine einzige Verantwortung zu erreichen.
2. Als die Klassen, die ich zuvor geschrieben habe, mehrere Gründe für die Änderung hatten, ist es am besten, sie neu zu überarbeiten.
Es gibt jedoch ein Problem mit dem Prinzip der Verwendung der einzelnen Verantwortung. Es gibt keinen klaren Abteilungsstandard für "Verantwortlichkeiten". Wenn die Verantwortlichkeiten zu detailliert sind, führt dies zu einer starken Zunahme der Anzahl der Schnittstellen und Implementierungsklassen, die die Komplexität erhöhen und die Wartbarkeit des Codes verringern. Bei Verwendung dieser Verantwortung müssen wir daher auch die spezifische Situation analysieren. Der Vorschlag ist, dass die Schnittstelle das Prinzip der einzelnen Verantwortung übernehmen und das Prinzip der einzelnen Verantwortung im Entwurf der Klasse so weit wie möglich erkennen muss. Es ist am besten, Änderungen in einer Klasse zu verursachen, wenn ein Grund verursacht wird.