SRP Weil bedingte Anweisungen die SRP überhaupt nicht verletzen, weil sie wie die switch case-Anweisung oder mehr als eine if-else-Anweisung mehr als eine Verantwortlichkeit berücksichtigen.   Es gibt zwei Fälle, also gibt es mehr als einen Grund, die Methode zu ändern.

Ich stimme überhaupt nicht zu. Das SRP soll mit einer Prise Salz interpretiert werden. Lesen Sie Onkel Bobs Artikel hier - er hat diesen Grundsatz geprägt.

Ich zitiere die wichtigen Bits:

  

Was definiert einen Grund, sich zu ändern?

     

Dieses Prinzip handelt von Menschen.

     

Wenn Sie ein Softwaremodul schreiben, möchten Sie sicherstellen, dass Änderungen nur dann von einer einzelnen Person oder einer eng verbundenen Gruppe von Personen stammen können, die eine eng definierte Geschäftsfunktion darstellen. Sie möchten Ihre Module von den Komplexitäten der Organisation als Ganzes isolieren und Ihre Systeme so gestalten, dass jedes Modul für genau diese eine Geschäftsfunktion verantwortlich ist (antwortet).

     

[...] Wenn Sie über diesen Grundsatz nachdenken, denken Sie daran, dass die Gründe für Veränderungen Menschen sind. Es sind Leute, die Änderungen anfordern. Und Sie wollen diese Menschen oder sich selbst nicht dadurch verwirren, dass sie den Code, den viele Menschen aus unterschiedlichen Gründen pflegen, zusammenmischen.

  

OCP Wenn ein neues Tier hinzugefügt wird, muss der Methode ein neuer Fall hinzugefügt werden, damit die Methode für Änderungen nicht geschlossen wird.

Richtig. Die Methode setzt eine bestimmte Reihe von Implementierungen voraus und ist nicht in der Lage, neue zu handhaben, ohne geändert zu werden.

  

LSP Jeder Zweig führt abhängig vom Untertyp des Tieres verschiedene Aktionen aus. Was ich glaube, verletzt den LSP?!

Es verletzt den LSP, aber aus einem anderen Grund. Wenn ich eine Giraffe hereinlassen würde, würde ich ein unerwartetes Ergebnis bekommen, eine leere Schnur. Dies bedeutet, dass die Methode für keinen Subtyp von Animal korrekt ist.

  

DIP Die bedingten Anweisungen nehmen eine Abhängigkeit an, die bedeutet, dass die Anweisungen von Details und nicht von Abstraktionen abhängen, die gegen den DIP verstoßen.

Technisch wahr, aber dies ist nur ein Nebeneffekt der Verletzung der anderen beiden oben genannten Prinzipien. Es ist nicht wirklich der Kern des Problems.

Denken Sie daran, dass Prinzipien keine Regeln sind, also seien Sie nicht zu streng / wörtlich, wenn Sie sie interpretieren. Pragmatismus und Verständnis dafür, warum ein Prinzip notwendig ist, sind der Schlüssel.

Ich stimme der Tatsache nicht zu, dass Ihr Beispielcode gegen den LSP verstößt. LSP ist wie folgt definiert:

  

Sei Φ (x) eine Eigenschaft, die über Objekte x vom Typ T nachweisbar ist. Dann sollte Φ (y) für Objekte y vom Typ S gelten, wobei S ein Subtyp von T ist.

Wenn Sie die zwei Ableitungen von Animal, nämlich Dog und Cat , und Ihre Methode getAnimalNoise angeben, treffen Sie keine Entscheidungen über eine beweisbare Eigenschaft des konkreten Objekts. Ihre Methode ist zu entscheiden, welches Geräusch zurückgegeben werden soll und nicht die Objekte von sich selbst.

Stellen Sie sich vor, Sie können die Anzahl der Beine für ein Tier festlegen.

Und wenn Ihr Dog das so überschreibt:

Wenn Sie jetzt eine Factory haben, die ein Animal

Und Sie rufen die Methoden setFront/setRearLegs auf, die Sie erwarten, dass die Ergebnisse 2 und 2 sind, aber tatsächlich ist das Ergebnis völlig anders, nämlich 2 und 4. Also ist dieses Beispiel fest an das übliche LSP-Beispiel mit Quadraten und Rechtecken gebunden . Aber für mich ist es ein genaueres Beispiel für eine Verletzung von beweisbaren Eigenschaften als in Ihrem Beispiel.

Update für die anderen Prinzipien

Ich stimme Ihnen zu, dass die anderen Prinzipien ebenfalls verletzt werden, aber für SRP stimme ich @dcastro zu.