Hallo Spa\u00df-Coder.<\/p>\n
In unserem letzten Artikel zur Serie \u00fcber Entwurfsmuster haben wir uns mit dem Einzelst\u00fcck (singleton)<\/em> <\/a>besch\u00e4ftigt. Es gibt aber noch weitere sog. Erzeugungsmuster. Mit diesen werden wir uns im Rahmen dieses Artikels besch\u00e4ftigen.<\/p>\n Die verbleibenden Erzeugungsmuster aus der Sammlung der Gang of Four sind:<\/p>\n Auch diese beiden Muster dienen dazu, ein Objekt zu erstellen, mit dem wir dann weiterarbeiten k\u00f6nnen. Aber warum wollen wir das? Hier gelten die gleichen Gr\u00fcnde, die wir auch schon bei der Abstrakten Fabrik <\/a>angef\u00fchrt haben. Wir wollen m\u00f6glichst auf new<\/span> verzichten, wenn wir uns in Teilen des Codes bewegen, die sich mit hoher Wahrscheinlichkeit \u00e4ndern werden.<\/p>\n Der Prototype<\/strong> verh\u00e4lt sich genau anders herum als ein Singleton. Immer dann, wenn wir uns ein Objekt des Prototypen holen, ist dies eine neue Instanz. Allerdings ist diese Instanz nicht immer ganz neu, sondern wird als Kopie einer Vorlage erstellt. Anschlie\u00dfend kann der Prototyp dann an die aktuellen Bed\u00fcrfnisse angepasst werden.<\/p>\n Der Builder<\/strong> erzeugt ein komplexes Objekt, indem er es aus einzelnen Bestandteilen zusammensetzt. Dieses Muster dient entweder der Wiederverwendung, wenn das Objekt aus verschiedenen Quellsystemen heraus erstellt werden soll oder es dient schlicht der Vereinfachung der Objekterstellung. Beim ersten Anwendungsfall m\u00f6chten wir wieder die Aspekte der Erstellung und der Repr\u00e4sentation voneinander trennen (Separation of Conerns<\/a>), beim zweiten geht es eher um besser lesbaren Code.<\/p>\n <\/p>\n Der Prototype hilft uns insbesondere dann, wenn die Erzeugung von Instanzen einer Klasse aufwendig oder kompliziert ist und die erstellten Objekte einander sehr \u00e4hnlich sind.<\/p>\n Am besten vergleichen l\u00e4sst sich das Muster mit der Erstellung von Dokumenten. Damit ich m\u00f6glichst schnell mit dem Erfassen des Inhalts starten kann, erstelle ich mein neues Dokument in der Regel nicht leer, sondern aus einer Vorlage, einem sog. Template.<\/p>\n Der Kern des Musters ist, dass ich aus einer Vorlage eine Kopie erstellen kann, die ich im Folgenden dann weiterverwende. Die Erstellung der Kopie hat das Ziel, eben nicht teuer, sondern m\u00f6glichst schlank zu sein.<\/p>\n <\/p>\n Nehmen wir einmal, wir m\u00f6chten Gespr\u00e4che dokumentieren. Dazu haben wir ein Formular auf einer Webseite, in das wir f\u00fcr die verschiedenen Gespr\u00e4chspunkte Eintr\u00e4ge machen k\u00f6nnen. Zus\u00e4tzlich gibt es in dem Gespr\u00e4chsprotokoll spezielle Eingaben, wie etwa das Datum, die Liste der Beteiligten und zum Schluss die M\u00f6glichkeit, Feedback in Form einer Bewertung abzugeben.<\/p>\n Von dieser Art der Gespr\u00e4chsprotokolle gibt es die verschiedensten Variationen:<\/p>\n Jedes dieser Formulare l\u00e4sst sich nur sehr aufwendig erstellen. Hier m\u00fcssen die Definitionen aus der Datenbank gelesen werden, bestimmte Steuerelemente initialisiert werden, Reihenfolgen festgelegt werden, …<\/p>\n Damit dies nicht jedes Mal aufs neue manuell durch den Client gemacht werden muss, ist es \u00fcber das Prototype-Muster m\u00f6glich, die Erzeugung in einer Klasse zu kapseln (etwa in eine Factory) und nur einmalig durchzuf\u00fchren. Sobald das Formular ein zweites Mal f\u00fcr ein anderes Gespr\u00e4ch verwendet werden soll, wird das Template einfach dupliziert und an den Client zur\u00fcckgegeben.<\/p>\n Im Beispiel nutzen wir f\u00fcr die Bestandteile des Gespr\u00e4chs die Praxis des Copy-Constructors<\/a>. Dabei wird dem Konstruktor eine Instanz vom gleichen Typ wie der Klasse in der wir uns befinden \u00fcbergeben. Die einzelnen Werte werden dann einfach den Klassenvariablen zugewiesen.<\/p>\n <\/p>\n Auch der Prototype l\u00e4sst sich durch Frameworks – wie etwa Spring – unterst\u00fctzt umsetzen. Dies deckt zwar nicht alle Anwendungsf\u00e4lle ab, sollte aber immer, wenn m\u00f6glich genutzt werden.<\/p>\n <\/p>\n Denkbar ist es, dass wir Muster miteinander kombinieren. Wenn es z.B. eine Familie von Produkten gibt, die alle recht \u00e4hnlich sind, aber in der Erstellung recht teuer, kann man dar\u00fcber nachdenken, eine Abstrakte Fabrik <\/a>zu erstellen, dessen Produkte Prototypen sind. Auch die Verwendung im Zusammenspiel mit einem teuer zu erstellenden Singleton<\/a> ist denkbar.<\/p>\n <\/p>\n Das Muster des Builders verwenden wir immer dann, wenn die Erstellung eines komplexen Objekts unabh\u00e4ngig von der Erzeugung der Bestandteile sein soll. Wenn es also keine Rolle spielt, in welcher Reihenfolge die Bestandteile des Objekts erzeugt werden.<\/p>\n Eine zweite M\u00f6glichkeit, den Builder einzusetzen ist, wenn die Erstellung eines Objekts einen internen Zustand erfordert, der dem Ersteller aber nicht bekannt ist oder bekannt sein soll.<\/p>\n Es gibt verschiedene M\u00f6glichkeiten, einen Builder zu implementieren und die Instanz hinterher abzurufen. Typisch ist etwa eine statische, interne Klasse Builder<\/em> innerhalb des Objekts, welches erstellt werden soll. Dies sieht dann wie folgt aus:<\/p>\n Hier wird der Builder also dem Konstruktor des zu erstellenden Objekts \u00fcbergeben. Dies hat den Vorteil, dass das Objekt auch mit anderen Buildern erstellt werden kann, etwa zu Testzwecken.<\/p>\n Eine andere M\u00f6glichkeit kann auch sein, dass der Builder selbst das Objekt erstellt und dann zur\u00fcck gibt. Welche Art gew\u00e4hlt wird h\u00e4ngt im Grunde vom Objekt ab und sollte je nach Situation gew\u00e4hlt werden.<\/p>\n Als sinnvoll hat sich herausgestellt, dass der Builder in Form eines Fluent Interface<\/a> implementiert wird. Dies vereinfacht den Aufruf und macht den Code zur Erstellung deutlich besser lesbar.<\/p>\n <\/p>\n Die in diesem Artikel vorgestellten Muster runden die Liste der Erzeugungsmuster aus der Sammlung der Gang of Four ab. Sie dienen zur\u00a0 Erstellung von Objekten in besonderen, immer wiederkehrenden Situationen.<\/p>\n Wir hoffen, dass die Beispiele euch gen\u00fcgend Anhaltspunkte daf\u00fcr gegeben haben, wann eines der Muster sinnvoll eingesetzt werden kann.<\/p>\n <\/p>\n Viel Spa\u00df beim Ausprobieren<\/p>\n Eure Spa\u00df-Coder<\/p>\n <\/p>\n Den Code zu unseren Beispielen k\u00f6nnt ihr auf Github finden:<\/p>\n <\/p>\n Dieser Artikel basiert neben unseren Erfahrungen auf den Ausf\u00fchrungen aus:<\/p>\n Hallo Spa\u00df-Coder. In unserem letzten Artikel zur Serie \u00fcber Entwurfsmuster haben wir uns mit dem Einzelst\u00fcck (singleton) besch\u00e4ftigt. Es gibt aber noch weitere sog. Erzeugungsmuster. Mit diesen werden wir uns im Rahmen dieses Artikels besch\u00e4ftigen. Die verbleibenden Erzeugungsmuster aus der Sammlung der Gang of Four sind: Prototyp (prototype) Erbauer (builder) Auch diese beiden Muster dienen […]<\/p>\n","protected":false},"author":1,"featured_media":971,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[90],"tags":[134,130,133],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/947"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=947"}],"version-history":[{"count":16,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/947\/revisions"}],"predecessor-version":[{"id":1047,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/947\/revisions\/1047"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/971"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=947"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=947"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=947"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Wann sind diese Entwurfsmuster sinnvoll anzuwenden?<\/h1>\n
Prototype<\/h2>\n
Beispiel<\/h3>\n
\n
public abstract class ConversationPrototype implements Conversation {\r\n public String title;\r\n public List<ConversationItem> conversationItems;\r\n\r\n public abstract ConversationPrototype clone();\r\n\r\n [...]\r\n}<\/pre>\npublic class ConversationInterview extends ConversationPrototype {\r\n\r\n @Override\r\n public ConversationInterview clone() {\r\n ConversationInterview conversation = new ConversationInterview();\r\n conversation.title = this.title;\r\n conversation.conversationItems = this.conversationItems\r\n .stream()\r\n .map(item -> new ConversationItem(item))\r\n .collect(Collectors.toList());\r\n\r\n return conversation;\r\n }\r\n}<\/pre>\npublic class ConversationItem {\r\n\r\n public String name;\r\n\r\n \/\/ Imagine a very complicated class that can only be created with lots of effort...\r\n\r\n public ConversationItem(String name) {\r\n this.name = name;\r\n }\r\n\r\n \/\/ Copy Constructor\r\n public ConversationItem(ConversationItem item) {\r\n this.name = item.name;\r\n \/\/ more copy code goes here\r\n }\r\n [...]\r\n}<\/pre>\nHinweis<\/h3>\n
Vermischung von Mustern<\/h3>\n
Builder<\/h2>\n
Beispiel<\/h3>\n
public class Person {\r\n private String name;\r\n private String surname;\r\n\r\n Person(Builder builder) {\r\n this.name = builder.name;\r\n this.surname = builder.surname;\r\n }\r\n\r\n public String getName() {\r\n return name;\r\n }\r\n\r\n public String getSurname() {\r\n return surname;\r\n }\r\n\r\n public static class Builder {\r\n private String name;\r\n private String surname;\r\n\r\n public Builder withName(String name) {\r\n this.name = name;\r\n return this;\r\n }\r\n\r\n public Builder withSurname(String surname) {\r\n this.surname = surname;\r\n return this;\r\n }\r\n\r\n public Person build() {\r\n return new Person(this);\r\n }\r\n }\r\n}<\/pre>\nZusammenfassung<\/h1>\n
\n
\n
\n