Java Allgemeine Methodenoptimierung: Verwenden der abstrakten übergeordneten Klasse, um ähnliche Anforderungsobjekte zu verarbeiten

In diesem Artikel wird untersucht, wie die Code -Redundanz beseitigt wird, indem abstrakte übergeordnete Klassen in Java eingeführt werden, wenn mehrere Anforderungsobjekte ähnliche Strukturen haben und dieselbe Geschäftslogik (z. B. Überprüfung) anwenden müssen. Durch die Übertragung gemeinsamer Felder und Verhaltensweisen in die abstrakte übergeordnete Klasse und die Nutzung von Polymorphismus kann die Methodenüberladung erheblich reduziert werden, wodurch die Wartbarkeit, Skalierbarkeit und Lesbarkeit der Code verbessert werden kann, wodurch wiederholtes Schreiben derselben Überprüfungslogik vermieden wird.

Optimieren Sie die allgemeine Verarbeitungslogik für ähnliche Anforderungsobjekte

In der Softwareentwicklung begegnen wir häufig auf solche Szenarien: Mehrere Datenübertragungsobjekte (DTOs) oder Anforderungsobjekte sind in der Struktur sehr ähnlich und müssen von derselben Geschäftslogik wie der Datenüberprüfung verarbeitet werden. Wenn Sie für jedes ähnliche Anforderungsobjekt eine unabhängige Verarbeitungsmethode schreiben, führt dies auch dann zu einer großen Menge an Code -Duplikation, die die Wartbarkeit und Lesbarkeit des Codes verringert.

Betrachten Sie die folgenden zwei Java -Datensatzstypen, mit denen Objekte erstellt und aktualisiert werden:

 öffentliche Aufzeichnungen createObjectralrest (
    CustomObjecta a,,
    CustomObjectB B,
    CustomObjectc c
) {}

öffentliche Aufzeichnungen updateObjectrequest (
    CustomObjecta a,,
    CustomObjectB b
) {}

Wenn wir die gleiche Überprüfungslogik für diese beiden Anforderungsobjekte ausführen müssen, besteht eine gängige Praxis darin, überlastete Verifizierungsmethoden separat zu erstellen:

 öffentliche Klasse RequestValidator {
    public void validateRequest (CreateObjectrequest createObjectrequest) {
        // viele der gleichen Verifizierungslogik ...
        System.out.println ("Validating createObjectrequest ...");
        // Beispiel: Überprüfen Sie, ob a und b leer sind, wenn (createObjectrequest.a () == null) {
            Neue illegalArgumentException werfen ("CustomObjecta kann nicht für CreateObjectrequest null sein.");
        }
        if (createObjectrequest.b () == null) {
            Neue IllegalArgumentException werfen ("CustomObjectB kann nicht für CreateObjectrequest null sein.");
        }
        // ... andere Überprüfung}

    public void validateRequest (updateObjectrequest updateObjectrequest) {
        // die gleiche große Menge an Überprüfungslogik ...
        System.out.println ("validieren updateObjectrequest ...");
        // Beispiel: Überprüfen Sie, ob a und b leer sind, wenn (updateObjectrequest.a () == null) {
            Neue IllegalArgumentException werfen ("CustomObjecta kann nicht für UpdateObjectrequest null sein.");
        }
        if (updateObjectrequest.b () == null) {
            Neue IllegalArgumentException werfen ("CustomObjectB kann nicht für UpdateObjectrequest null sein.");
        }
        // ... andere Überprüfung}
}

Obwohl diese Methode funktional machbar ist, gibt es offensichtlich eine Code -Redundanz. Wenn die Überprüfungslogik komplex wird oder geändert werden muss, muss sie an mehreren Stellen synchron aktualisiert werden, was äußerst anfällig für Fehler ist.

Verwendung abstrakter übergeordneter Klassen zur Implementierung der Code -Wiederverwendung

Um das obige Problem zu lösen, können wir die objektorientierten Merkmale von Java, insbesondere abstrakten Klassen und der Vererbung, verwenden, um diese Redundanz zu beseitigen. Die Kernidee besteht darin, die Felder und Verhaltensweisen zu identifizieren, die allen ähnlichen Anforderungsobjekten gemeinsam sind und sie in eine gemeinsame übergeordnete Klasse zusammenfassen.

1. Definieren Sie die abstrakte Elternklasse

Erstellen Sie zunächst eine abstrakte übergeordnete Klasse wie objectrequest, die Felder enthält, die von allen untergeordneten Anfragetypen geteilt werden.

 // Angenommen, die Basisklasse oder Schnittstelle von CustomObjecta und CustomObjectB ist CustomObject
öffentliche abstrakte Klasse objectrequest {
    geschütztes CustomObject a;
    geschütztes CustomObject B;

    // Konstruktor, Getter/Setter (falls erforderlich)
    public CustomObject geta () {
        Rückkehr a;
    }

    public CustomObject getb () {
        Rückkehr B;
    }
}

Anmerkungen:

• Hier sind CustomObjecta und CustomObjectB in CustomObjects einheitlich, vorausgesetzt, sie haben eine gemeinsame übergeordnete Klasse oder Schnittstelle, oder wir können sie durch Typenlöschungen verarbeiten. Wenn CustomObjecta und CustomObjectB in praktischen Anwendungen völlig unabhängige Typen sind, aber nur die gleichen Feldnamen haben, müssen komplexere generische oder Schnittstellenschemata berücksichtigt werden. Nach der Problembeschreibung sind sie jedoch "gleiche Felder", was bedeutet, dass sie abstrahiert werden können.
• Das Feld wird als geschützt oder öffentlich deklariert, sodass die Unterklasse über die Getter -Methode zugreifen oder Zugriff gewähren kann.

2. Die Unterklasse erbt die abstrakte Elternklasse

Lassen Sie die spezifischen Anforderungsobjekte (z. B. createObjectrequest und updateObjectrequest) diese abstrakte übergeordnete Klasse erben. Da Java -Datensatztypen Klassen nicht direkt erben können, können wir den Datensatz in die normale Klasse ändern oder auf die Logik der übergeordneten Klasse durch Kombinationen innerhalb der Aufzeichnung verweisen (dies verliert jedoch die polymorphe Bequemlichkeit, die durch Erbschaft gebracht wird). Um den durch Vererbung gebrachten Polymorphismus zu erreichen, entscheiden wir uns normalerweise dafür, die Aufzeichnung in die normale Klasse umzuwandeln.

 // createObjectrequest inherit objectrequest
öffentliche Klasse CreateObjectrequest erweitert objectrequest {
    private CustomObjectC C; // CreateObjectralrequest eindeutiges Feld öffentlich erstellenObjectrequest (CustomObjecta A, CustomObjectb B, CustomObjectC C) {
        this.a = a; // Feld aus der übergeordneten Klasse this.b = b; // Feld aus der übergeordneten Klasse this.c = c;
    }

    public CustomObjectC getC () {
        Rückkehr C;
    }
}

// updateObjectrequest inherit objectrequest
öffentliche Klasse updateObjectrequest erweitert objectrequest {
    // updateObjectrequest Es gibt kein eindeutiges Feld oder es gibt andere eindeutige Felder öffentlich updateObjectralrequest (CustomObjecta A, CustomObjectB B) {
        this.a = a; // Feld aus der übergeordneten Klasse this.b = b; // Feld aus der übergeordneten Klasse} geerbt
}

Hinweis: Die CustomObjecta- und CustomObjectB -Typen sind hier als CustomObjects in objectrequest einheitlich. Wenn CustomObjecta und CustomObjectB selbst keine Unterklassen von CustomObject sind, aber beide gemeinsame Eigenschaften haben, können A und B in objectrequest als ihre gemeinsame Schnittstelle oder Basisklassentyp deklariert werden. Der Einfachheit halber wird hier angenommen, dass sowohl CustomObjecta als auch CustomObjectB vom Typ CustomObject -Typ verwiesen werden können.

3.. Allgemeine Verarbeitungsmethoden refactorieren

Die Verifizierungsmethode muss nun nur die abstrakte übergeordnete Klasse als Parameter akzeptieren. Durch das Polymorphismus kann diese Methode alle von objectrequest geerbten Unterklasseninstanzen bewältigen.

 öffentliche Klasse RequestValidator {
    public void validateRequest (objectrequest objectrequest) {
        // Allgemeine Überprüfung der Logik, jetzt müssen Sie nur system.out.println schreiben ("Validierung generischer objectrequest ...");

        // Zugriff auf das gemeinsame Feld in der übergeordneten Klasse if (objectrequest.geta () == null) {
            Neue IllegalArgumentException werfen ("CustomObjecta kann nicht null sein.");
        }
        if (objectrequest.getb () == null) {
            Neue IllegalArgumentException werfen ("CustomObjectB kann nicht null sein");
        }

        // Wenn für bestimmte Unterklassen eine zusätzliche Validierung erforderlich ist, können Sie Instanz verwenden
        if (objectrequest Instance von createObjectrequest createRequest) {
            System.out.println ("Durchführen von CreateObjectrequest Spezifische Validierung.");
            if (createrequest.getC () == null) {
                Neue IllegalArgumentException werfen ("CustomObjectC kann nicht für CreateObJectrequest null sein.");
            }
        } else if (objectrequest instanceof updanceObjectrequest updateRequest) {
            System.out.println ("updateObjectrequest spezifische Validierung durchführen");
            // Eindeutige Überprüfung für updateObjectralrequest}
        // ... andere allgemeine Überprüfung}
}

Auf diese Weise zentralisieren wir die wiederholte Validierungslogik erfolgreich in einer Methode. Wenn die allgemeine Überprüfungslogik geändert oder erweitert werden muss, müssen Sie nur die Methode zur validierten (objectrequest objecrequest) ändern, die die Wartbarkeit und Skalierbarkeit des Codes erheblich verbessert.

Zusammenfassung und Best Practices

Die Verwendung abstrakter Elternklassen zur Optimierung gemeinsamer Methoden ist ein leistungsstarkes Code -Wiederverwendung -Muster in Java. Es funktioniert für die folgenden Szenarien:

• Mehrere Klassen haben eine große Anzahl der gleichen Felder und Verhaltensweisen : Diese Klassen gehören konzeptionell zur gleichen Klasse von Dingen, haben aber ihre eigenen einzigartigen Eigenschaften.
• Für diese ähnlichen Klassen sind die gleichen Operationen erforderlich : wie Überprüfung, Serialisierung, Konvertierung usw.

Vorteil:

• Redundanz reduzieren : Vermeiden Sie es wiederholt, dieselbe Geschäftslogik zu schreiben.
• Verbesserung der Wartbarkeit : Logische Modifikationen müssen nur an einem Ort vorgenommen werden.
• Verbesserte Skalierbarkeit : Die neu hinzugefügten ähnlichen Anforderungstypen können automatisch allgemeine Verarbeitungsleistung durch Erben der abstrakten übergeordneten Klasse erhalten.
• Verbesserung der Lesbarkeit : Die Codestruktur ist klarer und die Absicht ist klarer.

Anmerkungen:

• Überstrakt : Wenn es nur sehr wenige gemeinsame Punkte zwischen Klassen gibt oder wenn nicht verwandte Klassen zusammengezwungen werden, können dies zu einer Überkomplexdesign führen und die Lesbarkeit verringern.
• Vererbungsbeschränkungen : Java ist eine einzige Erbschaftssprache. Wenn eine Klasse andere Klassen geerbt hat, kann sie die allgemeine Logik nicht durch Erbschaft wiederverwenden. Zu diesem Zeitpunkt können Sie in Betracht ziehen, Schnittstellen mit Standardmethoden, Kombinationsmustern oder anderen Entwurfsmustern wie Generika zu kombinieren.
• Einschränkungen des Datensatztyps : Der Datensatztyp wurde in Java 16 eingeführt. Sein Entwurfsziel ist es, ein unveränderlicher Datenanbieter zu sein und andere Klassen nicht zu erben (kann aber Schnittstellen implementieren). Wenn Sie also den Polymorphismus mit Vererbung implementieren müssen, müssen Sie möglicherweise die Aufzeichnungen in die herkömmliche Klasse umwandeln.

Indem Entwickler rational mit Abstraktion und Vererbung rational unter Verwendung von Abstraktion und Vererbung mehr eleganter, robuster und einfacher schreiben, um den Java -Code aufrechtzuerhalten.

Das obige ist der detaillierte Inhalt vonJava Allgemeine Methodenoptimierung: Verwenden der abstrakten übergeordneten Klasse, um ähnliche Anforderungsobjekte zu verarbeiten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!