Designmuster

---

Entwurfsmuster (Entwurfsmuster) ist eine Reihe klassifizierter und katalogisierter Zusammenfassungen von Code-Entwurfserfahrungen, die wiederholt verwendet werden und den meisten Menschen bekannt sind. Der Zweck der Verwendung von Entwurfsmustern besteht darin, Code wiederzuverwenden, ihn für andere verständlicher zu machen und die Zuverlässigkeit des Codes sicherzustellen. Es besteht kein Zweifel, dass Entwurfsmuster eine Win-Win-Situation für uns selbst und andere darstellen, und dass Entwurfsmuster das Schreiben von Code zu einem echten Engineering machen;

---

Entwurfsmuster (engl. Design Patterns) sind Lösungen für wiederkehrende Probleme im objektorientierten Design. Dieser Begriff wurde in den 1990er Jahren von Erich Gamma und anderen aus dem Bereich des Architekturdesigns in die Informatik eingeführt. Die Bedeutung dieses Begriffs ist umstritten. Algorithmen sind keine Entwurfsmuster, da sich Algorithmen eher mit der Problemlösung als mit Entwurfsproblemen befassen. Entwurfsmuster beschreiben normalerweise eine Reihe von Klassen und Objekten, die eng miteinander interagieren. Entwurfsmuster bieten eine gemeinsame Sprache für die Diskussion von Softwaredesign, sodass Anfänger und andere Designer die Designerfahrung erfahrener Designer erfassen können. Entwurfsmuster liefern auch Ziele für das Software-Refactoring.

Mit dem wachsenden Interesse an Designmustern in der Softwareentwicklungsgemeinschaft wurden einige verwandte Monographien veröffentlicht, entsprechende Seminare wurden regelmäßig abgehalten und Ward Cunningham erfand WikiWiki, um Designmustererfahrungen zu kommunizieren.

Tipps: Dieses Tutorial erklärt Ihnen Schritt für Schritt das Konzept von Entwurfsmustern anhand von Java-Beispielen. Sie müssen also etwas über Java-Kenntnisse wissen.

Ausdrucksformat

Das Format zum Ausdruck eines Software-Entwurfsmusters variiert je nach Autor, z. B. Abteilung und Name. Das Format häufig verwendeter GoF-Beschreibungsmuster ist grob in die folgenden Teile unterteilt:

• Mustername: Jedes Muster hat seinen eigenen Namen, und der Mustername ermöglicht es uns, unser Design zu diskutieren.

• Problem: Es gibt bestimmte Anlässe, die beim objektorientierten Systemdesign immer wieder auftreten und dazu führen, dass wir ein bestimmtes Muster übernehmen.

• Lösung: Die Lösung des oben genannten Problems gibt die verschiedenen Komponenten des Designs, ihre Beziehungen, die Aufteilung der Verantwortlichkeiten und die Methoden der Zusammenarbeit an.

• Alias: Ein Muster kann mehr als einen Namen haben. Diese Namen sollten in diesem Abschnitt vermerkt werden.

• Motivation: In welchem ​​Fall dieses Muster verwendet wird, liegt in der Verantwortung der in diesem Abschnitt bereitgestellten Lösung (einschließlich des Problems und Kontexts).

• Anwendbarkeit: Auf welche Situationen ist das Muster anwendbar, der Hintergrund des Musters usw.

• Struktur: Dieser Teil häufig verwendeter Klassendiagramme und Interaktionsdiagramme veranschaulicht dieses Muster.

• Teilnehmer: Dieser Abschnitt enthält eine Liste der in diesem Muster verwendeten Klassen und Objekte und die Rollen, die sie im Design spielen.

• Kooperation: Beschreibt die Interaktion zwischen Klassen und Objekten in diesem Modus.

• Auswirkungen: Die Auswirkungen der Übernahme dieses Modells auf andere Teile des Softwaresystems, beispielsweise die Auswirkungen auf die Skalierbarkeit und Portabilität des Systems. Zu den Auswirkungen zählen auch negative Auswirkungen. In diesem Abschnitt sollten die Ergebnisse, Nebenwirkungen und Kompromisse (Kompromisse) der Verwendung dieses Musters beschrieben werden. Mögliche Techniken für das Muster oder vorgeschlagene Möglichkeiten zur Implementierung des Musters.

• Beispiel: Beschreiben Sie kurz, wie Muster in einer Programmiersprache verwendet werden.

• Bekannte Anwendungen: In der Branche bekannte Implementierungsbeispiele.

• Verwandte Muster: Dieser Abschnitt enthält andere verwandte Muster sowie Unterschiede zu anderen ähnlichen Mustern.

Tipp: Unser Tutorial zu Designmustern hilft Ihnen dabei, alles über Designmuster zu lernen. Wenn Sie Fragen haben, gehen Sie bitte zur PHP Chinese Community, um Ihre Fragen zu stellen, und begeisterte Internetnutzer werden sie für Sie beantworten.

Musterprinzipien

Jeder fängt an, auf Designmuster zu achten. Warum verwenden wir also Designmuster? Warum sollten wir mit so vielen Designmustern entwerfen?

Um ehrlich zu sein, habe ich es vorher nicht wirklich verstanden. Wenn ich nur zusehe, wie alle „Entwurfsmuster“ wiederholen, fühle ich mich ein wenig schwach. Also kaufte ich mir ein Buch über die Designmuster der „Gang of Four“ und es stellte sich heraus, dass ich es überhaupt nicht verstand: Ich schien es zu verstehen, als ich es las, vergaß es dann aber nach einer Weile . Vielleicht liegt es daran, dass ich relativ „dumm“ bin :)) Vor kurzem habe ich einige Erkenntnisse gewonnen. „Es ist besser, alleine glücklich zu sein, als zusammen glücklich zu sein“, das möchte ich gerne mit Ihnen teilen und hoffe, Sie können mir einen Rat geben

Warum sollten wir uns für „Design Pattern“ einsetzen? Der Hauptgrund besteht darin, Code wiederzuverwenden und die Wartbarkeit zu erhöhen.

Wie können wir also die Wiederverwendung von Code erreichen? Die OO-Welt hat mehrere Prinzipien ihrer Vorgänger: das „Open Closed Principal“-Prinzip, das Liskov-Substitutionsprinzip und das Synthese- und Wiederverwendungsprinzip. Entwurfsmuster implementieren diese Prinzipien, um die Wiederverwendung von Code zu erreichen und die Wartbarkeit zu erhöhen.

• Offen-Geschlossen-Prinzip

Dieses Prinzip wurde von „Bertrand Meyer“ vorgeschlagen. Der Originaltext lautet: „Software-Entitäten sollten für Erweiterungen offen, für Änderungen jedoch geschlossen sein.“ Das heißt, das Modul sollte für Erweiterungen geöffnet und für Änderungen geschlossen sein. Module sollten versucht werden, erweitert zu werden, ohne den Originalcode („Original“, bezogen auf den Originalcode) zu ändern. Wie also erweitern? Schauen wir uns das „Fabrikmuster“ an: Angenommen, es gibt einen Mann in Zhongguancun, der Raubkopien von CDs und pornografischen Filmen verkauft, und wir entwickeln für ihn eine „CD-Verkaufsverwaltungssoftware“. Wir sollten zunächst eine „CD“-Schnittstelle entwerfen. Wie im Bild gezeigt: [pre]______________|<>||. CD ||_____________|| Sell() || ||_____________|[/pre] Und Raubkopien und pornografische Filme sind seine Unterkategorien. Der Junge verwaltet diese Discs über „DiscFactory“. Der Code lautet:

publicclassDiscFactory{
publicstatic光盘
getDisc(Stringname){
return(光盘)Class.forName(name).getInstance();
}
}

Jemand möchte eine Raubkopie einer Festplatte kaufen, wie geht das?

public class boy{ public static void main(String【】 args){ CD d=DiscFactory.getDisc("Pirate Disc"} }

Wenn vorhanden Eines Tages hat das Gewissen dieses Kerls es herausgefunden und er begann, echte Software zu verkaufen. Es spielt keine Rolle, wir müssen nur eine weitere Unterkategorie von „CD“ mit dem Namen „Originalsoftware“ erstellen. Die ursprüngliche Struktur und der ursprüngliche Code müssen nicht geändert werden. Wie wäre es damit? Offen für Erweiterungen, geschlossen für Änderungen. „Offen-Geschlossenes Prinzip“ Das Fabrikmuster erweitert bestimmte Produkte. Wenn Sie diese „Fabrik“ erweitern möchten, wird es zum „abstrakten Fabrikmuster“.

• Richter-Substitutionsprinzip

Das Liskov-Substitutionsprinzip wurde von „Barbara Liskov“ vorgeschlagen. Wenn die übergeordnete Klasse aufgerufen wird, kann sie ausgeführt werden, wenn sie in eine Unterklasse geändert wird. Zum Beispiel: CD d=neue Raubkopien(); d. Wenn Sie die Kategorie „Raubkopien“ in die Kategorie „Pornofilme“ ändern möchten, ist dies problemlos möglich. Der Java-Compiler prüft, ob das Programm dem Liskov-Substitutionsprinzip entspricht. Erinnern Sie sich noch an ein Prinzip der Java-Vererbung? Die Zugriffsrechte der Override-Methode der Unterklasse dürfen nicht geringer sein als die Zugriffsrechte der entsprechenden Methode der übergeordneten Klasse. Wenn beispielsweise die Zugriffsberechtigung der Methode „Verkaufen“ in „CD“ „öffentlich“ ist, kann die Methode „Verkaufen“ in „Pirate Disc“ und „Raw Film“ nicht geschützt oder privat sein und die Zusammenstellung wird nicht bestanden. Warum ist das so? Denken Sie darüber nach: Wenn die Methode des „Verkaufs“ von „Raubkopien“ privat ist. Dann kann der folgende Code nicht ausgeführt werden: CD d=new raubkopiert disk(); d. Man kann sagen, dass das Liskov-Ersetzungsprinzip eine Grundlage für Vererbung und Wiederverwendung ist.

• Das Prinzip der Komposition und Wiederverwendung

bedeutet, weniger Vererbung und mehr Kompositionsbeziehungen zu verwenden. Ich habe einmal ein Programm wie dieses geschrieben: Es gibt mehrere Klassen, die sich mit der Datenbank befassen müssen, also schreibe ich eine Klasse für Datenbankoperationen, und dann erben andere Klassen, die sich mit der Datenbank befassen, diese. Infolgedessen habe ich später eine Methode der Datenbankoperationsklasse geändert, und alle Klassen mussten geändert werden. „Eine Bewegung wirkt sich auf den ganzen Körper aus“! Zielorientiert ist es, Schwankungen auf den kleinstmöglichen Bereich zu begrenzen.

In Java sollten Sie versuchen, für die Schnittstelle zu programmieren, anstatt Klassen zu implementieren. Auf diese Weise hat die Änderung einer Unterklasse keine Auswirkungen auf den Code, der ihre Methoden aufruft. Lassen Sie jede Kategorie so wenig Kontakt wie möglich mit anderen haben: „Sprich nicht mit Fremden.“ Auf diese Weise wird den Fischen im Teich kein Schaden zugefügt, wenn das Stadttor Feuer fängt. Nur wenn Skalierbarkeit und Wartbarkeit verbessert werden können

Sobald Sie diese Prinzipien verstanden haben und sich dann die Entwurfsmuster ansehen, geht es nur noch darum, wie Sie diese Prinzipien auf bestimmte Probleme umsetzen können. Zhang Wuji lernte Tai Chi, vergaß alle Bewegungen und besiegte die „Zwei Ältesten Xuan Mi“. Es wurde gesagt, dass er „keine Bewegungen im Kopf hatte“. Entwurfsmuster können als Tricks beschrieben werden. Wenn Sie zuerst alle Muster lernen, dann alle Muster vergessen und tun, was Sie wollen, kann dies als der höchste Zustand von OO bezeichnet werden. Haha, lustig, lustig! (JR)

Abhängigkeitsinversionsprinzip Die Abstraktion sollte nicht von Details abhängen, Details sollten auf

• Abhängigkeitsinversionsprinzip

<🎜 basieren > Programm zur Schnittstelle, nicht zur Implementierung. Versuchen Sie bei der Übergabe von Parametern oder in kombinierten Aggregationsbeziehungen, auf übergeordnete Klassen zu verweisen. Der Hauptgrund ist, dass beim Erstellen von Objekten verschiedene konkrete Objekte dynamisch erstellt werden können. Wenn einige konkrete Klassen relativ stabil sind, ist es natürlich nicht erforderlich, eine abstrakte Klasse als übergeordnete Klasse zu erstellen Beispiele für prinzipielle Anpassungsdienste, jedes

• Schnittstellenisolationsprinzip

eine Rolle, nicht mehr und nicht weniger, was Sie nicht tun sollten was auch immer Sie tun müssen Abstrakte Klasse Die abstrakte Klasse wird keine Instanzen haben

• Abstrakte Klasse

  Die Klasse

wird von Unterklassen geerbt und enthält im Allgemeinen die gemeinsamen Attribute und Methoden dieses Systems. Hinweis: In einer guten Vererbungsbeziehung sollten nur Blattknoten konkrete Klassen sein und andere Knoten sollten abstrakte Klassen sein, was bedeutet, dass konkrete Klassen nicht vererbt werden. Fügen Sie so viel allgemeinen Code wie möglich in abstrakte Klassen ein. 7 Demeters Gesetz des minimalen Wissensprinzips. Sprechen Sie nicht mit Fremden.

Inhalte, die in diesem Designmuster-Tutorial-Handbuch behandelt werden

Dieses Designmuster-Tutorial behandelt die Einführung aller Designmuster, einschließlich Factory-Muster, abstraktes Factory-Muster, Singleton-Muster (Singleton-Muster), Builder-Muster ( Builder-Muster), Prototyp-Muster (Prototyp-Muster) usw.

Tipp: Jedes Kapitel dieses Tutorials enthält viele Java-Beispiele, die Ihnen helfen, Entwurfsmuster besser zu erlernen und zu verstehen.