Generative Muster, Teil 2

4.1 Builder

Builder ist ein generatives Entwurfsmuster, das eine Möglichkeit bietet, ein zusammengesetztes Objekt zu erstellen.

Trennt die Konstruktion eines komplexen Objekts von seiner Darstellung, sodass derselbe Konstruktionsprozess zu unterschiedlichen Darstellungen führen kann.

Starke Seiten:

• ermöglicht es Ihnen, die interne Darstellung des Produkts zu ändern;
• isoliert den Code, der Konstruktion und Präsentation implementiert;
• ermöglicht eine genauere Kontrolle über den Designprozess.

Schwache Seiten:

• der Algorithmus zum Erstellen eines komplexen Objekts sollte nicht davon abhängen, aus welchen Teilen das Objekt besteht und wie sie zusammenpassen;
• Der Bauprozess muss unterschiedliche Darstellungen des zu bauenden Objekts liefern.

Ein gutes Beispiel ist die HttpRequest-Klasse, die über eine Unterklasse HttpRequest.Builder verfügt, mit der Instanzen der HttpRequest-Klasse erstellt und ihre Gültigkeit sichergestellt werden können.

4.2 Verzögerte Initialisierung

Bei der verzögerten Initialisierung handelt es sich um eine Programmiertechnik, bei der ein ressourcenintensiver Vorgang (Erstellung von Objekten, Wertberechnung) unmittelbar vor der Verwendung des Ergebnisses ausgeführt wird.

Somit erfolgt die Initialisierung „auf Abruf“ und nicht im Voraus. Eine ähnliche Idee findet in verschiedenen Bereichen Anwendung: zum Beispiel bei der On-the-Fly-Zusammenstellung und dem Just-in-Time-Logistikkonzept.

Ein Sonderfall der verzögerten Initialisierung – das Erstellen eines Objekts zum Zeitpunkt des Zugriffs – ist eines der generativen Designmuster. Es wird normalerweise in Verbindung mit Mustern wie Factory Method, Loner und Proxy verwendet.

Starke Seiten:

• Die Initialisierung wird nur dann durchgeführt, wenn sie wirklich benötigt wird;
• Die Erstinitialisierung der Anwendung wird beschleunigt: Alles, was verschoben werden kann, wird verschoben.

Schwache Seiten:

• Es ist nicht möglich, die Reihenfolge, in der Objekte initialisiert werden, explizit festzulegen.
• Beim ersten Zugriff auf das Objekt kommt es zu einer Verzögerung, die kritisch sein kann, wenn parallel ein anderer ressourcenintensiver Vorgang ausgeführt wird. Aus diesem Grund muss sorgfältig geprüft werden, ob die Verwendung einer verzögerten Initialisierung in Multithread-Softwaresystemen sinnvoll ist.

Erinnern Sie sich, wie Sie beim Schreiben von web.xml die Startreihenfolge der Servlets dort angeben konnten? Dies ist genau das Ergebnis von Lazy Loading. Tomcat erstellt Servlet-Objekte beim ersten Zugriff.

4.3 Objektpool

Ein Objektpool ist ein übergeordnetes Entwurfsmuster, eine Menge initialisierter und gebrauchsfertiger Objekte. Wenn das System ein Objekt benötigt, wird es nicht erstellt, sondern aus dem Pool entnommen. Wenn ein Objekt nicht mehr benötigt wird, wird es nicht zerstört, sondern in den Pool zurückgegeben.

Das Objekt-Pooling wird verwendet, um die Leistung zu verbessern, wenn das Erstellen eines Objekts zu Beginn eines Jobs und dessen Zerstörung am Ende kostspielig ist. Die Leistungssteigerung macht sich vor allem dann bemerkbar, wenn Objekte häufig erstellt und zerstört werden, aber nur eine geringe Anzahl davon gleichzeitig vorhanden ist.

Ein Objektpool ist nützlich, wenn ein Objekt andere Ressourcen als den Speicher besitzt, beispielsweise Netzwerk-Sockets. Oder wenn die Sammlung von Objekten einen erheblichen Teil des Computerspeichers einnimmt und viel „Müll“ entsteht.

Wie Sie sich erinnern, führt Tomcat jede Anfrage in einem separaten Thread aus. Threads werden jedoch nicht jedes Mal neu erstellt, sondern im Thread-Pool gespeichert. Dies ermöglicht eine schnellere Ausführung von Anfragen: Wenn ein Thread benötigt wird, wird dieser einfach aus dem Pool entnommen. Die Frage ist übrigens: Wie würde man den laufenden Thread in den Pool legen und aus dem Pool nehmen?