Geben Sie Beispiele zur Analyse der Bedeutung des Richter -Ersatzprinzips für die Java -Entwurfsmusterprogrammierung an

Das Ersatzprinzip von Rich, OCP, als das hochrangige Prinzip von OO, befürwortet die Verwendung von "Abstraktion" und "Polymorphismus", um die statische Struktur im Design in eine dynamische Struktur zu verwandeln, um das Gehäuse des Designs aufrechtzuerhalten. "Abstract" ist eine Funktion der Sprache. "Polymorphismus" wird durch ererbte Semantik umgesetzt.

Das Richter -Ersatzprinzip enthält die folgenden 4 Bedeutungen:

1. Unterklassen können abstrakte Methoden der übergeordneten Klasse implementieren, können jedoch nicht abstrakte Methoden der übergeordneten Klasse überschreiben.
2. Sie können der Unterklasse Ihre eigenen einzigartigen Methoden hinzufügen.
3. Wenn eine untergeordnete Klasse eine übergeordnete Klassenmethode überschreibt oder implementiert, sind die Voraussetzungen einer Methode (d. H. Die formalen Parameter einer Methode) lockerer als die Eingabeparameter der übergeordneten Klassenmethode.
4. Wenn eine Unterklasse -Methode die abstrakte Methode der übergeordneten Klasse implementiert, ist die Postkondition der Methode (d. H. Der Rückgabewert der Methode) strenger als die übergeordnete Klasse.

Jetzt können wir die oben genannten vier Bedeutungen erklären.

Unterklassen können abstrakte Methoden der übergeordneten Klasse implementieren, können jedoch nicht abstrakte Methoden der übergeordneten Klasse überschreiben.

Wenn wir Systeme entwerfen, entwerfen wir häufig Schnittstellen oder abstrakte Klassen und implementieren dann Unterklassen abstrakte Methoden. Das Richter -Ersatzprinzip wird hier tatsächlich verwendet. Es ist leicht zu verstehen, dass Unterklassen die abstrakte Methode der übergeordneten Klasse implementieren können. Tatsächlich müssen Unterklassen die abstrakte Methode der übergeordneten Klasse vollständig implementieren, auch wenn sie eine leere Methode schreiben, andernfalls werden sie einen Fehler kompilieren und melden.

Der entscheidende Punkt des Richter-Substitution-Prinzips ist, dass es die nicht abstrakten Methoden der Elternklasse nicht abdecken kann. Jede gut implementierte Methode in der übergeordneten Klasse besteht darin, tatsächlich eine Reihe von Spezifikationen und Verträgen festzulegen. Obwohl nicht alle Unterklassen dazu gezwungen werden, diesen Spezifikationen einzuhalten, wird das gesamte Vererbungssystem das gesamte Vererbungssystem schädigen, wenn die Unterklasse diese nicht-abstraktischen Methoden willkürlich ändern. Das Prinzip des Lizur -Ersatzes drückt diese Bedeutung aus.

In der objektorientierten Designidee bringt das Erben dieser Funktion große Bequemlichkeit für das Design des Systems, aber es gibt auch einige Risiken, die daraus resultieren. Die folgenden Beispiele werden verwendet, um das Risiko einer Erbschaft zu veranschaulichen. Wir müssen die Funktion des Subtrahierens von zwei Zahlen ausfüllen, und die Klasse A ist dafür verantwortlich.

 Klasse A {public int func1 (int a, int b) {return ab; }} public class Client {public static void main (string [] args) {a a = new a (); System.out.println ("100-50 ="+A.Func1 (100, 50)); System.out.println ("100-80 ="+A.Func1 (100, 80)); }}

Auslaufergebnisse:

 100-50 = 50100-80 = 20

Später müssen wir eine neue Funktion hinzufügen: Vervollständigen Sie die Hinzufügung von zwei Zahlen und summieren Sie sie dann mit 100, und Klasse B ist verantwortlich. Das heißt, Klasse B muss zwei Funktionen ausfüllen:
Die beiden Zahlen subtrahieren.
Fügen Sie zwei Zahlen hinzu und fügen Sie dann 100 hinzu.
Da die Klasse A die erste Funktion implementiert hat, müssen Sie nach der Klasse B der Klasse A nur die zweite Funktion ausfüllen. Der Code ist wie folgt:

 Klasse B erweitert einen {public int func1 (int a, int b) {return a+b; } public int func2 (int a, int b) {return func1 (a, b) +100; }} public class Client {public static void main (String [] args) {b b = new B (); System.out.println ("100-50 ="+B.Func1 (100, 50)); System.out.println ("100-80 ="+B.Func1 (100, 80)); System.out.println ("100+20+100 ="+B.Func2 (100, 20)); }}

Nach Abschluss der Klasse B ist das Run -Ergebnis:

 100-50 = 150100-80 = 180100+20+100 = 220

Wir fanden heraus, dass die Subtraktionsfunktion, die ursprünglich normal ausgeführt wurde, normalerweise einen Fehler hatte. Der Grund dafür ist, dass wenn die Methode der Klasse B die Methode benannt hat, die Methode der übergeordneten Klasse versehentlich neu schreibt und alle Codes verursacht, die Subtraktionsfunktionen ausführen, um die Umschreibe -Methode der Klasse B aufzurufen, was zu Fehlern in der ursprünglichen normalen Funktion führt. In diesem Beispiel trat nach Bezugnahme auf die Funktion der Basisklasse A und das Wechsel in Unterklasse B eine Ausnahme auf. In der tatsächlichen Programmierung erfüllen wir häufig neue Funktionen, indem wir die übergeordnete Klassenmethode neu schreiben. Obwohl es einfach zu schreiben ist, ist die Wiederverwendbarkeit des gesamten Vererbungssystems relativ schlecht, insbesondere wenn Polymorphismus häufiger verwendet wird, ist die Wahrscheinlichkeit von Programmbetriebsfehlern sehr hoch. Wenn Sie die übergeordnete Klassenmethode neu schreiben müssen, ist der allgemeinere Ansatz: die ursprüngliche Elternklasse und die untergeordnete Klasse erben eine beliebtere Basisklasse, entfernen Sie die ursprüngliche Vererbungsbeziehung und verwenden Sie stattdessen Abhängigkeit, Aggregation, Kombination und andere Beziehungen.