Java >> Java Tutorial >  >> Java

Objektorientierte Designprinzipien

Ein guter Softwareentwickler baut eine Software nach den richtigen Designprinzipien. Wenn Sie Entwurfsmuster und objektorientierte Konzepte lernen, aber keine Prinzipien lernen, dann tun Sie sich als Entwickler einen Bärendienst. Ohne Designprinzipien werden Sie eine Software ohne Herz und ohne zu bedienende Funktionalität erstellen. Ich hoffe, Sie möchten das nicht tun.

In diesem Beitrag werde ich versuchen, einige Designprinzipien zu erklären, auf die ich gestoßen bin oder die ich durch meine Erfahrung gelernt habe. Wenn Sie eines dieser Prinzipien nicht verstehen, kommentieren Sie bitte den Beitrag und ich werde Ihre Fragen beantworten.

Programmierung für Schnittstelle und nicht für Implementierung

Beim Erstellen des Designs können Sie darüber nachdenken, wie Sie Ihren Code wiederverwenden oder so gestalten können, dass Sie ihn in Zukunft bei Bedarf erweitern können. ODER Sie müssen minimale Änderungen vornehmen, wenn Sie sich ändern müssen. Ein Designprinzip, das in solchen Fällen helfen kann, ist Schnittstellen zu programmieren statt direkt zu implementieren .

Für Variablen, Rückgabetypen von Methoden oder Argumenttypen von Methoden – verwenden Sie Schnittstellen. Dies hilft, Schnittstellen nach Belieben zu implementieren.

Prinzip der Einzelverantwortung

Eine Klasse, eine Methode sollte immer eine einzelne Verantwortung oder eine einzelne Funktionalität implementieren. Das Einfügen von mehr als einer Funktionalität in ein Objekt kann die Funktionalität in Zukunft stören, wenn es Änderungen gibt. Um zukünftige Änderungen zu reduzieren, implementieren Sie Ihren Code immer nach dem Prinzip der Einzelverantwortung.

Liskov-Substitutionsprinzip

Dieses Prinzip besagt, dass Objekte durch Instanzen ihrer Unterklassen ersetzbar sein sollten, ohne die Korrektheit des Programms zu verändern.

Um dies zu verstehen, schauen wir uns ein einfaches Objekt und Unterklassen dieses Objekts Bird an

public class Bird
{
    void fly()
    {
       // Fly function for bird
    }
}

public class Parrot extends Bird
{
    @Override
    void fly()
    {

    }
}

public class Ostrich extends Bird
{
   // can't implement fly since Ostrich doesn't fly
}

Papagei als Vogel kann fliegen, aber Strauß als Vogel kann nicht fliegen. Wenn wir also eine solche Implementierung verwenden, wird sie das Prinzip der Liskov-Substitution verletzen.

Open-Closed-Prinzip

Das Open-Closed-Prinzip bewirkt, dass Objekte und Methoden für Erweiterungen offen, aber für Änderungen geschlossen sein sollten. Oft sind die Anforderungen zu Beginn des Designs und der Implementierung nicht klar, wir müssen das offene geschlossene Prinzip verwenden, um das anfängliche Design zu implementieren, und wenn sich die Anforderungen langsam ändern, wird es einfach, sie in das Design aufzunehmen.

Prinzip der Schnittstellentrennung

Dieses Prinzip erfordert, dass der Client nicht gezwungen werden sollte, eine Schnittstelle zu implementieren, wenn er diese nicht verwendet. Mit anderen Worten, stellen Sie sicher, dass Ihre Schnittstellen übersichtlich sind und nur einzelne Funktionen implementieren. Wenn die Schnittstelle mehr als eine Funktionalität hat, kann es für den Client unnötig sein, alle Funktionalitäten zu implementieren, wenn er nur eine benötigt.

Delegationsprinzip

Machen Sie nicht alles selbst, sondern delegieren Sie die Funktionalitäten an die jeweiligen Klassen. Delegierung ist eine Art Beziehung zwischen Objekten, bei der ein Objekt bestimmte Funktionen weiterleiten kann, um Arbeit an andere Objekte zu erledigen (vorausgesetzt, diese Objekte implementieren diese Funktionen).

Prinzip der Abhängigkeitsinversion

Dieses Prinzip ist eine Art Entkopplungsverhalten für Softwaremodule. High-Level-Module sollten nicht von Low-Level-Modulen abhängen. Im Allgemeinen hängt die Gestaltung von High-Level-Klassen von Low-Level-Klassen ab. Wenn Sie jedoch nach jeder Designrevision Low-Level-Klassen ändern müssen, ist dies ein schlechtes Design. Um ein solches Problem zu vermeiden, erstellen wir eine Abstraktionsschicht. Low-Level-Klassen werden basierend auf der Abstraktionsschicht erstellt.

Wenn dieses Prinzip verwendet wird, verwenden High-Level-Klassen Schnittstellen als Abstraktionsschicht, um mit Low-Level-Klassen zu arbeiten, anstatt direkt mit Low-Level-Klassen zu arbeiten.

Referenzen

  1. Zehn objektorientierte Designprinzipien – SOLID Principles
  2. Designprinzipien – Designprinzipien


Java-Tag