it-swarm.com.de

Programmierung SOLID Prinzipien

Mit der Zeit konnte ich zwei Teile von SOLID - das "S" und "O" verstehen.

"O" - Ich habe das Open Closed-Prinzip mit Hilfe des Vererbungs- und Strategiemusters gelernt.

"S" - Ich habe beim Erlernen von ORM das Prinzip der Einzelverantwortung gelernt (die Persistenzlogik wird von Domänenobjekten entfernt).

Was sind in ähnlicher Weise die besten Regionen/Aufgaben, um andere Teile von SOLID (das „L“, „I“ und „D“) zu lernen?

Verweise

  1. msdn - Gefahren von Verstößen SOLID Prinzipien in C #
  2. channel9 - Anwenden von S.O.L.I.D.-Prinzipien in .NET/C #
  3. OOPS-Prinzipien (SOLID-Prinzipien)
44
LCJ

Ich war vor ein paar Monaten in Ihren Schuhen, bis ich einen sehr hilfreichen Artikel fand.

Jedes Prinzip lässt sich anhand realer Situationen erklären, mit denen jeder Softwareentwickler in seinen Projekten konfrontiert sein kann. Ich schneide hier ab und zeige auf die Referenz - S.O.L.I.D. Softwareentwicklung, Schritt für Schritt .

Wie in den Kommentaren erwähnt, gibt es eine weitere sehr gute PDF-Lesung - Pablos SOLID Software Development .

Darüber hinaus gibt es einige gute Bücher, in denen SOLID Prinzipien ausführlicher beschrieben werden - Good Book on SOLID Software Development .

Bearbeitung und Kommentar einer kurzen Zusammenfassung für jedes Prinzip:

  • "S" - Das Prinzip der Einzelverantwortung wird von den Anforderungen des Unternehmens bestimmt, um Änderungen zu ermöglichen. „Ein einziger Grund zur Änderung“ hilft Ihnen zu verstehen, welche logisch getrennten Konzepte zusammengefasst werden sollten, indem Sie das Geschäftskonzept und den Kontext anstelle des technischen Konzepts allein berücksichtigen. In another words, ich habe gelernt, dass jede Klasse eine einzige Verantwortung haben sollte. Die Verantwortung besteht darin, nur die zugewiesene Aufgabe zu erfüllen

  • "O" - Ich lernte das Open Closed-Prinzip und begann, "Komposition gegenüber Vererbung zu bevorzugen" und als solche Klassen zu bevorzugen, die keine virtuellen Methoden haben und möglicherweise versiegelt sind, deren Erweiterung jedoch von Abstraktionen abhängt.

  • "L" - Ich habe das Liskov-Substitutionsprinzip mithilfe des Repository-Musters für die Verwaltung des Datenzugriffs gelernt.

  • "Ich" - Ich habe das Prinzip der Schnittstellentrennung kennengelernt, indem ich gelernt habe, dass Clients nicht gezwungen werden sollten, Schnittstellen zu implementieren, die sie nicht verwenden (wie im Membership Provider in ASP.NET 2.0). Die Schnittstelle sollte also nicht „viele Verantwortlichkeiten“ haben.
  • "D" - Ich habe das Prinzip der Abhängigkeitsinversion kennengelernt und angefangen, Code zu ändern, der leicht zu ändern ist . Einfacher zu ändern bedeutet niedrigere Gesamtbetriebskosten und höhere Wartbarkeit.

Da eine nützliche Ressource von CodePlex in Kommentaren erwähnt wurde, wird auf SOLID am Beispiel verwiesen

(enter image description here

55
Yusubov

(I) Schnittstellentrennung und (D) Ependenzinversion können durch Unit-Test und Verspottung erlernt werden. Wenn Klassen ihre eigenen Abhängigkeiten erstellen, können Sie keine guten Komponententests erstellen. Wenn sie von einer zu breiten Schnittstelle abhängen (oder überhaupt keine Schnittstelle), ist es nicht sehr offensichtlich, was verspottet werden muss, um Ihre Unit-Tests durchzuführen.

11

Liskov-Substitutionsprinzip erlaubt es Ihnen grundsätzlich nicht, die Implementierungsvererbung zu überbeanspruchen: Sie sollten die Vererbung niemals nur für die Wiederverwendung von Code verwenden (es gibt eine Komposition dafür)! Wenn Sie sich an LSP halten, können Sie ziemlich sicher sein, dass tatsächlich eine "Ist-Beziehung" zwischen Ihrer Oberklasse und Ihrer Unterklasse besteht.

Es heißt, dass Ihre Unterklassen alle Methoden der Unterklasse auf ähnliche Weise wie die Implementierung der Methoden in der Unterklasse implementieren müssen. Sie sollten niemals eine Methode mit der Implementierung von NOP überschreiben oder null zurückgeben, wenn der Supertyp eine Ausnahme auslöst. Wenn Sie eine Methode überschreiben, sollten Sie den Vertrag der Methode aus der Oberklasse beachten. Eine Möglichkeit, sich gegen einen Verstoß gegen dieses Prinzip zu verteidigen, besteht darin, eine implementierte Methode niemals außer Kraft zu setzen. Extrahieren Sie stattdessen eine Schnittstelle und implementieren Sie diese Schnittstelle in beiden Klassen.

Interface Segregation Principle, Single Responsibility Principle und High Coehsion Principle von GRASP hängen irgendwie zusammen; Sie beziehen sich auf die Tatsache, dass ein Unternehmen nur für eine Sache verantwortlich sein sollte, damit es nur einen Grund für Änderungen gibt, sodass Änderungen sehr einfach durchgeführt werden können.

Wenn eine Klasse eine Schnittstelle implementiert, muss sie alle Methoden dieser Schnittstelle implementieren und verwenden. Wenn es Methoden gibt, die in dieser bestimmten Klasse nicht benötigt werden, ist die Schnittstelle nicht gut und muss in zwei Schnittstellen aufgeteilt werden, von denen eine nur die von der ursprünglichen Klasse benötigten Methoden enthält. Aus einem POV, der sich auf das vorherige Prinzip bezieht, kann davon ausgegangen werden, dass Sie keine großen Schnittstellen erstellen können, sodass deren Implementierung den LSP beschädigen könnte.

Sie können Abhängigkeitsinversion im Factory-Muster sehen; hier sowohl die High-Level-Komponente (der Client) als auch die Low-Level-Komponente (einzelne zu erstellende Instanz) hängen von der Abstraktion (der Schnittstelle) ab. Eine Möglichkeit, es in einer Ebenenarchitektur anzuwenden: Sie sollten keine Schnittstelle zu einer Ebene in der implementierten Ebene definieren, sondern in dem aufgerufenen Modul. Beispielsweise sollte die API für die Datenquellenschicht nicht in die Datenquellenschicht geschrieben werden, sondern in die Geschäftslogikschicht, in der sie aufgerufen werden muss. Auf diese Weise erbt/hängt die Datenquellenschicht von dem in der Geschäftslogik definierten Verhalten (also der Inversion) ab und nicht umgekehrt (wie dies normalerweise der Fall wäre). Dies bietet Flexibilität im Design und ermöglicht es der Geschäftslogik, ohne Codeänderung mit einer anderen, völlig anderen Datenquelle zu arbeiten.

8
m3th0dman