Eine Einführung in die sieben Prinzipien des objektorientierten Designs in C#

1: Single-Responsibility-Prinzip (SRP)

1. Definition: Ein Objekt sollte nur eine einzige Verantwortung enthalten, und die Verantwortung ist vollständig in einer Klasse gekapselt

Oder: Soweit Wenn eine Klasse betroffen ist, sollte es nur einen Grund für ihre Änderung geben.

2. Analyse: Je mehr Verantwortlichkeiten eine Klasse (oder so groß wie ein Modul oder so klein wie eine Methode) trägt, desto unwahrscheinlicher ist es, dass sie wiederverwendet wird, und wenn eine Klasse zu viele Verantwortlichkeiten trägt, wird sie verwendet Aufgrund der Verknüpfung dieser Verantwortlichkeiten kann eine Änderung einer der Verantwortlichkeiten Auswirkungen auf den Betrieb anderer Verantwortlichkeiten haben. Die Verantwortlichkeiten einer Klasse umfassen hauptsächlich zwei Aspekte: Datenverantwortung und Verhaltensverantwortung werden durch ihre Attribute widergespiegelt, während Verhaltensverantwortung durch ihre Methoden widergespiegelt wird. Das Prinzip der Einzelverantwortung ist eine Richtlinie zum Erreichen einer hohen Kohäsion und einer geringen Kopplung. Es ist das einfachste, aber am schwierigsten anzuwendende Prinzip. Es erfordert, dass Designer die unterschiedlichen Verantwortlichkeiten von Klassen erkennen und trennen Um die vielfältigen Verantwortlichkeiten von Klassen zu entdecken, müssen Designer über ausgeprägte Analyse- und Designfähigkeiten sowie einschlägige Refactoring-Erfahrung verfügen.

3. Beispiel:

Das Beispiel zeigt, dass die „Anmeldefunktion“ eines Java-basierten C/S-Systems durch die folgende Anmeldeklasse (Login) implementiert wird:
Die Single Dafür wird nun das Verantwortungsprinzip Refactor verwendet.

2: Open-Closed-Prinzip (OCP)

1. Definition: Eine Software-Entität sollte offen für Erweiterungen und geschlossen für Änderungen sein. Das heißt, beim Entwerfen eines Moduls sollte das Modul erweitert werden, ohne dass es geändert wird. Das heißt, das Verhalten des Moduls kann geändert werden, ohne den Quellcode zu ändern.

2. Analyse: Das Öffnungs- und Schließprinzip wurde 1988 von Bertrand Meyer vorgeschlagen. Es ist eines der wichtigsten Prinzipien im objektorientierten Design. In der Definition des Offen-Geschlossen-Prinzips kann sich eine Software-Entität auf ein Softwaremodul, eine aus mehreren Klassen zusammengesetzte Teilstruktur oder eine unabhängige Klasse beziehen. Abstraktion ist der Schlüssel zum Offen/Geschlossen-Prinzip. Das Öffnungs- und Schließprinzip kann auch durch ein spezifischeres „Prinzip der Kapselung von Variationen“ (EVP) beschrieben werden, das das Finden und Kapseln der variablen Faktoren des Systems erfordert.

3: Liskov-Substitutionsprinzip (LSP)

1. Definition: Wenn es für jedes Objekt o1 vom Typ S ein Objekt o2 vom Typ T gibt, so dass das Verhalten aller Programme P definiert mit T ändert sich nicht, wenn alle Objekte o1 durch o2 ersetzt werden, dann ist Typ S ein Untertyp des Typs T

Oder: Alle Referenzbasisklassen (übergeordnete Klasse) müssen in der Lage sein, Objekte ihrer Unterklassen transparent zu verwenden .

2. Analyse: Das Liskov-Substitutionsprinzip wurde von Barbara Liskov, der Turing-Preisträgerin 2008, der ersten weiblichen Doktorin der Informatik in den Vereinigten Staaten, Professorin am MIT und Professorin Jeannette Wing an der Carnegie Mellon University entwickelt . Vorgeschlagen im Jahr 1994.

Das Liskov-Substitutionsprinzip kann auf eine beliebte Weise ausgedrückt werden: Wenn Sie Basisklassenobjekte in Software verwenden können, müssen Sie in der Lage sein, deren Unterklassenobjekte zu verwenden. Wenn die Basisklasse durch ihre Unterklassen ersetzt wird, generiert das Programm keine Fehler oder Ausnahmen. Das Gegenteil ist nicht der Fall. Wenn eine Software-Entität eine Unterklasse verwendet, kann sie die Basisklasse möglicherweise nicht verwenden. Das Liskov-Substitutionsprinzip ist eine der wichtigen Methoden zur Implementierung des Öffnungs- und Schließprinzips. Da Unterklassenobjekte überall dort verwendet werden können, wo Basisklassenobjekte verwendet werden, versuchen Sie, Basisklassentypen zum Definieren von Objekten im Programm zu verwenden und diese dann zur Laufzeit zu verwenden . Bestimmen Sie den Typ seiner Unterklasse und ersetzen Sie das Objekt der übergeordneten Klasse durch das Objekt der Unterklasse.

Viertens: Prinzip der Abhängigkeitsinversion (DIP)

1. Definition: High-Level-Module sollten nicht von Low-Level-Modulen abhängen, sie sollten alle auf Abstraktionen basieren. Abstraktion sollte nicht von Details abhängen, Details sollten von Abstraktion abhängen

Oder: Programm für Schnittstellen, nicht für Implementierung. (Programmieren zu einer Schnittstelle, nicht zu einer Implementierung.)

2. Analyse: Das Prinzip der Abhängigkeitsinversion ist die dritte Spalte des Engineering Notebook, das 1996 von Robert C. Martin für „C++ Reporter“ geschrieben und später hinzugefügt wurde Zu seinem 2002 erschienenen Klassiker „Agile Software Development, Principles, Patterns, and Practices“.

Einfach ausgedrückt bedeutet das Prinzip der Abhängigkeitsinversion: Code sollte von abstrakten Klassen abhängen, nicht von konkreten Klassen; die Programmierung sollte für Schnittstellen oder abstrakte Klassen erfolgen und nicht für die Programmierung von konkreten Klassen. Der Schlüssel zur Verwirklichung des Öffnungs- und Schließprinzips ist die Abstraktion, und die konkrete Implementierung wird aus der Abstraktion abgeleitet. Wenn das Öffnungs- und Schließprinzip das Ziel des objektorientierten Designs ist, ist das Abhängigkeitsinversionsprinzip die Hauptmethode des objektorientierten Designs.

Eine der gängigen Methoden zur Implementierung des Abhängigkeitsinversionsprinzips besteht darin, abstrakte Klassen im Code zu verwenden und konkrete Klassen in der Konfigurationsdatei zu platzieren.

Kopplung zwischen Klassen

Null-Kopplungsbeziehung

Konkrete Kopplungsbeziehung

Abstrakte Kopplungsbeziehung

Das Abhängigkeitsinversionsprinzip erfordert, dass der Client abhängig ist Abstrakte Kopplung Die abstrakte Kopplung ist der Schlüssel zum Abhängigkeitsinversionsprinzip.

Abhängigkeitsinjektion

Konstruktorinjektion: Instanzvariablen über den Konstruktor injizieren.

Setter-Injection: Injizieren Sie Instanzvariablen über die Setter-Methode.

Schnittstelleninjektion: Instanzvariablen über Schnittstellenmethoden injizieren.

5: Prinzip der Schnittstellentrennung (ISP)

1. Definition: Der Client sollte sich nicht auf Schnittstellen verlassen, die er nicht benötigt. Beachten Sie, dass sich die Schnittstelle in dieser Definition auf eine definierte Methode bezieht.

Oder: Sobald eine Schnittstelle zu groß ist, muss sie in kleinere Schnittstellen aufgeteilt werden. Der Client, der die Schnittstelle verwendet, muss nur die damit verbundenen Methoden kennen.

2. Analyse: Das Prinzip der Schnittstellenisolation bezieht sich auf die Verwendung mehrerer spezialisierter Schnittstellen anstelle der Verwendung einer einzigen Gesamtschnittstelle. Jede Schnittstelle sollte eine relativ unabhängige Rolle einnehmen, nicht mehr und nicht weniger. Sie sollte nichts tun, was sie nicht tun sollte, sondern alles tun, was sie tun sollte.

(1) Eine Schnittstelle repräsentiert nur eine Rolle, und jede Rolle hat ihre eigene spezifische Schnittstelle. Dieses Prinzip kann als „Rollenisolationsprinzip“ bezeichnet werden.

(2) Die Schnittstelle stellt nur die Verhaltensweisen bereit, die der Client benötigt, das heißt, die Verhaltensweisen, die der Client nicht benötigt, sollten so klein wie möglich sein möglich, anstatt eine große Gesamtschnittstelle bereitzustellen.

Wenn Sie das Schnittstellenisolationsprinzip zum Aufteilen einer Schnittstelle verwenden, müssen Sie zunächst das Prinzip der Einzelverantwortung erfüllen, eine Reihe verwandter Vorgänge in einer Schnittstelle definieren und unter der Voraussetzung einer hohen Kohäsion die Anzahl der Methoden in der Schnittstelle verringern Schnittstelle Je besser. Sie können beim Entwerfen des Systems benutzerdefinierte Dienste verwenden, d. h. Schnittstellen mit unterschiedlichen Breiten für verschiedene Clients bereitstellen, nur die Verhaltensweisen bereitstellen, die Benutzer benötigen, und Verhaltensweisen ausblenden, die Benutzer nicht benötigen.

Sechs: Composite-Reuse-Prinzip (CRP), auch bekannt als Composition/Aggregate-Reuse-Prinzip (CARP)

1. Definition: Verwenden Sie Objekte so oft wie möglich Komposition statt Vererbung, um eine Wiederverwendung zu erreichen. (Bevorzugen Sie die Zusammensetzung von Objekten gegenüber der Vererbung als Wiederverwendungsmechanismus.)

2. Analyse: Das Prinzip der Zusammensetzung und Wiederverwendung bezieht sich auf die Verwendung einiger vorhandener Objekte in einem neuen Objekt durch Assoziationsbeziehungen (einschließlich Kombinationsbeziehungen und Aggregationsbeziehungen). . Vorhandene Objekte werden zu einem Teil eines neuen Objekts. Das neue Objekt erreicht den Zweck, seine vorhandenen Funktionen wiederzuverwenden, indem es Methoden bestehender Objekte delegiert und aufruft. Kurz gesagt: Verwenden Sie Kompositions-/Aggregationsbeziehungen so oft wie möglich und Vererbung seltener.

Beim objektorientierten Design können vorhandene Designs und Implementierungen in verschiedenen Umgebungen durch zwei grundlegende Methoden wiederverwendet werden, nämlich durch Kompositions-/Aggregationsbeziehungen oder durch Vererbung.
Vererbung und Wiederverwendung: einfach zu implementieren und leicht zu erweitern. Zerstört die Kapselung des Systems; die von der Basisklasse geerbte Implementierung ist statisch, kann zur Laufzeit nicht geändert werden und verfügt nicht über genügend Flexibilität, sodass sie nur in begrenzten Umgebungen verwendet werden kann. („White-Box“-Wiederverwendung)

Kombinations-/Aggregationswiederverwendung: Der Kopplungsgrad ist relativ gering und die Operationen von Mitgliedsobjekten werden selektiv zur Laufzeit aufgerufen; („Black Box“-Wiederverwendung)
Kombination/Aggregation kann das System flexibler machen, die Kopplung zwischen Klassen verringern und Änderungen in einer Klasse haben relativ geringe Auswirkungen auf andere Klassen, daher wird Kombination/Aggregation im Allgemeinen bevorzugt Zweitens müssen Sie bei der Verwendung der Vererbung das Liskov-Ersetzungsprinzip befolgen, um das Problem zu verstehen und die Komplexität zu verringern Das System erfordert einen sorgfältigen Einsatz der Wiederverwendung von Vererbungen.

Sieben: Gesetz der Demeter (LoD), auch bekannt als Prinzip des geringsten Wissens (LKP)

1 Definition:

(1) Sprechen Sie nicht mit „Fremden“. .“ Die englische Definition lautet: Sprich nicht mit Fremden.

(2) Kommuniziere nur mit deinen direkten Freunden. Die englische Definition lautet: Sprechen Sie nur mit Ihren unmittelbaren Freunden.

(3) Jede Softwareeinheit verfügt über minimale Kenntnisse über andere Einheiten und ist auf die Softwareeinheiten beschränkt, die eng mit der eigenen Einheit verbunden sind. Die englische Definition lautet: Jede Einheit sollte nur begrenzte Kenntnisse über andere Einheiten haben: nur Einheiten, die „eng“ mit der aktuellen Einheit verbunden sind) ein Forschungsprojekt namens „Demeter“. Einfach ausgedrückt bedeutet das Demeter-Gesetz, dass eine Software-Entität so wenig wie möglich mit anderen Entitäten interagieren sollte. Auf diese Weise wirkt sich die Änderung eines Moduls so wenig wie möglich auf andere Module aus und die Erweiterung ist relativ einfach. Dies stellt eine Einschränkung der Kommunikation zwischen Softwareeinheiten dar. Dies erfordert eine Begrenzung der Breite und Tiefe der Kommunikation zwischen Softwareeinheiten.

Das obige ist der detaillierte Inhalt vonEine Einführung in die sieben Prinzipien des objektorientierten Designs in C#. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!