Java Design Patterns – Sechs Prinzipien von Design Patterns

Sechs Designprinzipien

Prinzip der Einzelverantwortung

Sie dürfen nicht mehr als einen Grund für einen Klassenwechsel haben . Laienhaft ausgedrückt ist eine Klasse nur für eine Verantwortung verantwortlich.

Ursprung des Problems: Klasse T ist für zwei verschiedene Verantwortlichkeiten verantwortlich: Verantwortung P1 und Verantwortung P2. Wenn Klasse T aufgrund von Änderungen in den Anforderungen der Verantwortung P1 geändert werden muss, kann dies zu einer Fehlfunktion der Funktion der Verantwortung P2 führen, die ursprünglich normal ausgeführt wurde.

Zusammenfassung in einem Satz: Füllen Sie eine Klasse nicht einfach mit einer kleinen Menge Code für ein Bild

Richter-Substitutionsprinzip

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

2. Unterklassen können ihre eigenen einzigartigen Methoden hinzufügen.

3. Wenn eine Methode einer Unterklasse eine Methode einer übergeordneten Klasse überschreibt, sind die Voraussetzungen der Methode (d. h. die formalen Parameter der Methode) lockerer als die Eingabeparameter der Methode der übergeordneten Klasse.

4. Wenn eine Methode einer Unterklasse eine abstrakte Methode einer übergeordneten Klasse implementiert, sind die Nachbedingungen der Methode (d. h. der Rückgabewert der Methode) strenger als die der übergeordneten Klasse.

Zusammenfassung in einem Satz: Versuchen Sie, die implementierten Methoden der übergeordneten Klasse nicht neu zu schreiben. Sie können andere Methoden wie Schnittstellen verwenden, um das

Abhängigkeitsinversionsprinzip

Hochrangige Module sollten nicht von untergeordneten Modulen abhängen, beide sollten von ihren Abstraktionen abhängen; Details sollten von Abstraktionen abhängen;

Hier ist ein Beispiel zur Veranschaulichung:

import java.util.LinkedList;  
import java.util.Queue;  
  
  
  
interface IEAT  
{  
    public void eat();//抽象吃这个动作  
}  
class EatApple implements IEAT  
{  
  
    @Override  
    public void eat()   
    {  
        //这里是吃苹果  
        System.out.print("eat a apple");  
          
    }  
}  
class EatWater implements IEAT  
{  
  
    @Override  
    public void eat() {  
        // 这里是吃水  
        System.out.print("dringk water");  
          
    }  
      
}  
public class Human  
{  
    public void dosomething(IEAT ieat)//我爱吃东西，吃什么呢，看传入什么  
    {  
        ieat.eat();  
    }  
    /* 
    public void dosomething(String food)//我爱吃东西，吃什么呢，看传入什么 
    { 
        if(food.equals("apple")) 
        { 
            //吃苹果 
        } 
        if(food.equals("water")) 
        { 
            //喝水 
        } 
    } 
    */  
    public static void main(String[] args)  
    {  
        Human human=new Human();  
        /* 
        human.dosomething("apple"); 
        human.dosomething("water"); 
         */  
        //给你吃个苹果  
        human.dosomething(new EatApple());  
        //再给你喝点水  
        human.dosomething(new EatWater());  
    }  
}

Die Kommentare sind unsere häufig verwendeten Methoden. Diese Methode ist für die Erweiterung sehr ungeeignet, denn wenn man Bananen oder Wassermelonen essen möchte, muss man in Dosomething viele Urteile schreiben. Während ich schreibe, gerate ich durcheinander.

Also um es in einem Satz zusammenzufassen: Verwenden Sie abstrakte Schnittstellen, um dieselbe Aktion zu beschreiben und die Kopplung zwischen den Personen und Objekten zu reduzieren, die die Aktion ausführen

Prinzip der Schnittstellenisolation

Ein Client sollte sich nicht auf Schnittstellen verlassen, die er nicht hat Bedarf; Die Abhängigkeit einer Klasse von einer anderen Klasse sollte auf der kleinsten Schnittstelle basieren.

Ursprung des Problems: Klasse A hängt von Klasse B über Schnittstelle I ab, und Klasse C hängt von Klasse D über Schnittstelle I ab. Wenn Schnittstelle I nicht die Mindestschnittstelle für Klasse A und Klasse B ist, dann Klasse B und Klasse D muss Methoden implementieren, die sie nicht benötigen.

Um es in einem Satz zusammenzufassen: Genau wie Fische und Menschen haben Fische zwei Aktionen: Schwimmen und Kiemenatmen, und Menschen haben zwei Aktionen: Gehen und Essen. Diese vier Aktionen können nicht in einer Schnittstelle geschrieben werden Aktionen können nicht in einer Schnittstelle geschrieben werden. Alle Aktionen sind enthalten. Es muss in zwei Schnittstellen speziell für Fische und Menschen aufgeteilt werden.

Demeter-Gesetz

Demeter-Gesetz Auch als das Geringste bezeichnet Dieses bekannte Prinzip wurde erstmals 1987 von Ian Holland von der Northeastern University in den Vereinigten Staaten vorgeschlagen. Laienhaft ausgedrückt: Je weniger eine Klasse über die Klassen weiß, von denen sie abhängt, desto besser. Mit anderen Worten, für die abhängige Klasse sollte die Logik, egal wie komplex die Logik ist, so weit wie möglich in der Klasse gekapselt werden, und außer den bereitgestellten öffentlichen Methoden werden keine Informationen nach außen gelangen.

Das ist etwas schwer zu merken: Vater1<-Kind1, Vater2<-Kind2, Vater1 und Vater2 sollten versuchen, über Vater2 auf Kind2 zuzugreifen direkt in der Klasse. . Wie können Untergebene beiläufig auf die Kinder des Leiters zugehen?

Dazu gibt es nichts zu sagen: Versuchen Sie, Änderungen zu erreichen, indem Sie das Verhalten von Software-Entitäten erweitern, anstatt vorhandenen Code zu ändern.