Übersicht
Das Erscheinungsmuster, über das ich heute sprechen werde, ist ein relativ einfaches Designmuster. In der täglichen Entwicklung verwenden Sie es möglicherweise auch von Zeit zu Zeit, aber Sie haben vielleicht nicht gedacht, dass es eins ist Designmodell. Dieser Artikel beginnt mit einigen Beispielen, um den in diesem Artikel erläuterten Darstellungsmodus so umfassend wie möglich zu erläutern. Ich hoffe, es ist für Sie von Vorteil.
Einleitung
Der Zweck des Einfügens eines Zitats hier besteht darin, Sie daran zu erinnern, wann Sie das Erscheinungsmuster in Ihrer täglichen Entwicklung verwenden.
Vielleicht wird Ihr Chef eine solche Aufgabe für Sie arrangieren. Dies kann ein Kernmodul sein, und das Modul wird eine seiner Funktionen haben, aber Ihr Chef möchte möglicherweise nur, dass Sie ihm eine Schnittstelle zum Aufrufen zur Verfügung stellen. Er wird Ihnen Folgendes sagen: Hallo Xiao Ming, unser aktuelles System benötigt eine Kernfunktion P0, damit Sie sie implementieren können. Sie müssen mir nur eine Schnittstelle geben, die ich aufrufen kann. Ich muss die interne Logik Ihres Codes nicht kennen. Tun Sie es einfach.
Wenn Ihnen solche Aufgaben oft zugewiesen werden, sollten Sie meiner Meinung nach den Erscheinungsmodus beherrschen.
Definition
Das Erscheinungsmuster stellt eine einheitliche Schnittstelle für den Zugriff auf eine Gruppe von Schnittstellen in einem Subsystem bereit. Das Fassadenmuster definiert eine High-Level-Schnittstelle, die die Verwendung von Subsystemen erleichtert.
Nicht-Erscheinungsmodus
Hier verwende ich das Beispiel aus dem Buch „Dahua Design Patterns“. Stellen Sie sich nun vor, Sie wären ein Aktieninvestor (der Blogger handelt nur nicht mit Aktien und ich weiß nicht, ob hier etwas nicht stimmt. Wenn ja, tun Sie einfach so, als hätten Sie es nicht gesehen. ^_^) , und Sie möchten einige Finanzmanagementaktivitäten durchführen. Sie interessieren sich für zwei Aktien, eine Staatsanleihe und eine Immobilie.
Wenn Sie diesen Code jetzt schreiben würden, könnte Ihr Code-Framework wie das folgende Klassendiagramm aussehen:
Aufgrund der Logik werden hier nur Aktien aufgeführt anderer Finanzmanagementaktivitäten steht im Einklang mit der Logik der Bestände. Redundanter Code hat nicht mehr Vorteile als den Platzbedarf.
StockA.java
public class StockA { private int stockCount = 0; public void sell(int count){ stockCount -= count; System.out.println("卖了" + count + "支 A 股票"); } public void buy(int count){ stockCount += count; System.out.println("买了" + count + "支 A 股票"); } public int getStockCount() { return stockCount; } }
Der folgende Code ist für Finanzmanager gedacht. Für eine einfache Kauf- und Verkaufslogik müssen Finanzmanager so viel Codeverarbeitung aufwenden.
Investors.java
public class Investors { public static void main(String[] args) { StockA stockA = new StockA(); StockB stockB = new StockB(); NationalDebt debt = new NationalDebt(); RealEstate estate = new RealEstate(); stockA.buy(100); stockB.buy(200); debt.buy(150); estate.buy(120); stockA.sell(100); stockB.sell(200); debt.sell(150); estate.sell(120); } }
Der oben genannte Code wurde ohne Verwendung des Darstellungsmodus geschrieben. Mit anderen Worten: Der unten erwähnte Darstellungsmodus kann den Code einfacher und klarer machen.
Darstellungsmodus
Im obigen Nicht-Erscheinungsmodus sehen wir eine Codelogik, die nicht sehr benutzerfreundlich ist. Der Darstellungsmodus kann auf einer höheren Kapselungsebene basieren, um für den Anrufer transparenter zu sein. Das Folgende ist das modifizierte Erscheinungsmodus-Klassendiagramm:
FundFacade.java
public class FundFacade { private StockA stockA = null; private StockB stockB = null; private NationalDebt debt = null; private RealEstate estate = null; public FundFacade() { stockA = new StockA(); stockB = new StockB(); debt = new NationalDebt(); estate = new RealEstate(); } public void buyAll(int count) { stockA.buy(count); stockB.buy(count); debt.buy(count); estate.buy(count); } public void sellAll(int count) { stockA.sell(count); stockB.sell(count); debt.sell(count); estate.sell(count); } public void buyStockA(int count) { stockA.buy(count); } public void sellNationalDebt(int count) { debt.sell(count); } }
Der obige Code ist die Kernklasse des Aussehens: FundFacade. Alle Vorgänge im Finanzmanagementsystem können über diese Klasse implementiert werden. Mit diesem Kurs können Sie problemlos Finanzmanagementprojekte wie Aktien, Staatsanleihen und Immobilien durchführen, ohne sich Gedanken über deren Verarbeitung machen zu müssen. Das ist eine gute Sache für die Benutzer, nicht wahr?
Werfen wir einen Blick auf die Bedienung des Benutzers (natürlich spiegelt das obige Diagramm die meisten Effekte wider). Dies ist die Codelogik des Benutzers:
Investors.java
public class Investors { public static void main(String[] args) { FundFacade facade = new FundFacade(); facade.buyAll(120); facade.buyStockA(50); facade.sellAll(80); } }
Sehen Sie, der Benutzer muss der FundFacade-Klasse nur mitteilen, was er kaufen, was er verkaufen, wie viel er kaufen und wie viel er verkaufen soll, und schon kann der Zweck erreicht werden. Es ist so praktisch.
Sehen Sie sich den Code von Bestand A an. Tatsächlich gibt es keine wesentlichen Änderungen. Dies ist auch der Reiz des Darstellungsmodus. Sie müssen den Code des ursprünglichen Subsystems nicht ändern. Sie müssen nur eine Sache tun und eine Kapselung auf höherer Ebene erstellen. Natürlich habe ich hier einige einfache Änderungen vorgenommen, um auf StockA zuzugreifen. Da es für Benutzer transparent sein muss, muss mein Subsystem nicht mehr für Benutzer offen sein, oder? Weil wir bereits professionelle Diplomaten haben – FundFacade.
StockA.java
class StockA { private int stockCount = 0; void sell(int count){ stockCount -= count; System.out.println("卖了" + count + "支 A 股票"); } void buy(int count){ stockCount += count; System.out.println("买了" + count + "支 A 股票"); } int getStockCount() { return stockCount; } }
Darstellungsmuster ist ein relativ einfaches Designmuster, das Sie leicht beherrschen und verwenden können. Ich möchte nur sagen, dass der Darstellungsmodus auch gewisse Einschränkungen hat. Ich glaube, Sie haben es entdeckt.
Da wir alle Operationen auf dem Subsystem an die FundFacade-Klasse übergeben, sind wir durch die FundFacade-Klasse eingeschränkt. Die obige FundFacade-Klasse implementiert beispielsweise keine separaten Operationen für StockB, sodass wir nicht nur für StockB arbeiten können, es sei denn, Sie kapseln eine Schnittstelle zum Betrieb von StockB in der FundFacade-Klasse.
Anwendung des Darstellungsmodus
In der obigen Beschreibung wissen wir nicht nur, wie man den Darstellungsmodus verwendet, sondern verstehen auch die Einschränkungen des Darstellungsmodus, daher sollten wir eine objektive Haltung einnehmen und selektiv vorgehen Benutze es. Hier ist ein Beispiel dafür, wie ich den Darstellungsmodus in meiner Arbeit verwende.
Der Chef des aktuellen Projekts hat mich gebeten, ein bestimmtes Modul in einem System zu implementieren. Ich denke, das sollte ein Kernmodul sein. Die Funktion dieses Moduls besteht darin, zu prüfen, ob alle Dateien in einem Ordner vertrauliche Informationen enthalten. Es wird viele kleine Untermodule in diesem Modul geben (natürlich ist es dem Chef egal, was diese Untermodule tun), wie z. B. Mustervergleich von AC-Automaten, vollautomatische Dekomprimierung komprimierter Dateien, verschiedene Formatdateien (doc/xls /ppt/zip/eml/rtf/pdf usw., die meisten Dateiformate sind grundsätzlich vorhanden), Protokollsystem usw.
Ich kann dem Chef unmöglich sagen, dass die Funktion, die Sie erledigen möchten, das ist, was Sie zuerst tun sollten, was Sie als nächstes tun sollten, was Sie als nächstes tun sollten, was Sie noch einmal tun sollten...
Oh, oh mein Gott. Es ist so nervig, kannst du es zusammenfassen? (Natürlich sind dies nur meine mentalen Aktivitäten. Tatsächlich habe ich den Chef nicht gebeten, meinen Entwurfsprozess zu erklären.)
Nach der Kapselung muss ich dem Chef nur sagen, dass er diese Methode dieser Klasse aufrufen soll Es wird in Ordnung sein. Auf diese Weise muss sich der Chef nicht um die interne Logik kümmern. Es liegt zwar in Ihrer Verantwortung, wenn etwas schief geht, aber es sollte in Ihrer Verantwortung liegen. Ha ha. . .
Okay, das war's mit dem Blödsinn. Unabhängig davon, ob es sich um die ausführliche Erklärung des schwerwiegenden Musters oben oder um den Unsinn unten handelt, hoffe ich, dass Sie damit das Entwurfsmuster in diesem Artikel vollständig verstehen, lernen und rational verwenden können.
Das Obige ist der Inhalt des Java-Designmusters – Erscheinungsmuster. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!