Erzeugungsmuster. Kapselung der Objekt-Erzeugung

Transkript

1 Erzeugungsmuster Kapselung der Objekt-Erzeugung

2 Definition Erzeugungsmuster dienen für die Lose Koppelung, bei der erst zur Laufzeit der Typ des zu erzeugenden Objekts festgelegt wird. Abstract Factory Factory Methode Sicherstellung, dass von einer Klasse nur genau ein (oder beschränkt viele) Objekt(e) existieren. Singleton/Multiton Wiederverwendung bereits vorhandener Objekte Object Pool

3 Abstract Factory Konfigurierbare Erzeugung von Objekten

4 Problem/Umfeld Das System soll unabhängig sein von der Art der Objekt- Erzeugung. Die konkret zu benutzende Klasse soll erst zur Laufzeit festgelegt werden müssen. Zu Compile-Zeit sollen nur die Schnittstellen festgelegt werden müssen. Die konkret zu benutzenden Objekte einer Produktfamilie sollen konfigurierbar sein.

5 Lösung/Struktur Quelle:

6 Beispiel: Übersicht Quelle:

7 Beispiel: Abstract Factory, Abstract/Concrete Product Abstract Factory: public interface GUIFactory { public Button createbutton(); Abstract Product: public interface Button { void paint(); Konkrete Factory für OSX: public class OSXFactory implements GUIFactory public Button createbutton() { return new OSXButton(); Konkreter OSX-Button: public class OSXButton implements Button public void paint() { System.out.println("OSXButton"); Konkrete Factory für Windows: public class WinFactory implements GUIFactory public Button createbutton() { return new WinButton(); Konkreter Windows-Button: public class WinButton implements Button public void paint() { System.out.println("WinButton"); Quelle:

8 Beispiel: Client Client: public static void main(string[] args) throws Exception { GUIFactory factory = null; final String appearance = randomappearance(); // liefert OSX oder Windows zurueck if (appearance.equals("osx")) { factory = new OSXFactory(); else if (appearance.equals("windows")) { factory = new WinFactory(); else { throw new Exception("No such operating system"); final Button button = factory.createbutton(); button.paint(); Quelle:

9 Vorteile Durch das Abschirmen der konkreten Klassen wird der Clientcode allgemeingültig. Es ist kein Code für spezielle Fälle notwendig. Flexibilität. Objektfamilien können ausgetaucht werden, ohne dass der Clientcode verändert werden muss. Einfache Erweiterung mit neuen Produktfamilien. Neue Klassen können sehr einfach ins System integriert werden. Nur die Factory-Schnittstelle muss angepasst werden. Wiederverwendbarkeit. Konkrete Klassen können Mitglieder verschiedener Produktfamilien sein.

10 Nachteile Der Code wird komplexer Pro Objektfamilie eine zusätzliche Klasse (Factory) (Indirektion verlangsamt den Code)

11 Verweis auf andere Muster Factory Methode (Erzeugungs-Methode) Eine Methode erzeugt ein konkretes Produkt, währenddessen bei Abstract Factory eine Factory zum Erzeugen einer Produktfamilie dient Einfacher als AbstractFactory, aber weniger flexibel Entkoppelt den Client vom konkreten Typ

12 Factory Methode Der Client erzeugt den «richtigen» Creator, welcher dann das passende Objekt herstellt.

13 Singleton Einzelstück

14 Umfeld/Zweck Es soll sichergestellt werden, dass von einer Klasse nur genau ein Exemplar (Instanz) existiert. Der Zugriff auf dieses Exemplar soll global möglich sein.

15 Lösung Das Singleton Pattern erzeugt (und verwaltet) eine einzige Instanz von diesem Typ Die öffentliche statische getinstance() Methode erlaubt den globalen Zugriff auf dieses Objekt. Da die instance-variable statisch ist, gibt es diesen Wert nur einmal (pro Java-VM Instanz).

16 Lösung public class Singleton { private static Singleton instance; //globale Methode zum Erhalten der Instanz. public static Singleton getinstance() { if (instance == null) return new Singleton(); return instance; private Singleton() { // privater Constructor

17 Vorteile Zugriffskontrolle. Das Singleton kapselt seine eigene Erstellung und kann damit kontrollieren, wann und wie der Zugriff erfolgt. Spezialisierung. Ein Singleton kann abgeleitet werden, um ihm neue Funktionalität zuweisen zu können. Die Integration in bestehenden Code gestaltet sich einfach. Welche Unterklasse genutzt werden soll, kann dynamisch zur Laufzeit entschieden werden. Lazy-Creation. Singletons können erst dann erzeugt werden, wenn sie wirklich gebraucht werden.

18 Nachteile Die ausgiebige Verwendung von Singletons führt zu den gleichen Problemen wie globale Variablen. Singletons können nicht aufgeräumt werden (GC). Durch die globale Verfügbarkeit wird das Singleton überall in der Applikation verfügbar. Falls das Singleton Daten enthält, ist dies eher fragwürdig. Ob eine Klasse ein Singleton verwendet, wird aus deren Schnittstelle nicht klar, sondern nur aus deren Implementierung.

19 Verweis auf andere Muster Multiton für die Erzeugung von genau k (nummerierten) Instanzen Prototyp: Erzeugen einer Instanz als Clone (exakte Kopie) eines existierenden Objektes (zum Beschleunigen des Erzeugungs-Prozesses).

20 Object Pool Wiederverwendung von Objekten

21 Umfeld Es soll eine Menge von Objekten verwendet / verwaltet werden deren Erzeugung sehr aufwändig oder teuer ist, oder deren Anzahl aus Sicherheits- oder Ressourcen- Gründen beschränkt werden soll. Die Objekte werden nur relativ kurz verwendet, d.h. die Erzeugungszeit ist im Vergleich zur effektiven Verwendungszeit überproportional lang.

22 Lösung Ein ObjectPool verwaltet die Instanzen der wiederverwendbaren Objekte. Jeder Client, welcher eine Instanz benötigt, holt diese beim ObjectPool. Sobald der Client seine Aufgabe erfüllt hat, gibt er das Objekt zurück Der ObjectPool räumt das Objekt auf und behält es bis zur nächsten Verwendung.

23 Lösung/Struktur/Implementation

24 Vorteile Teuer zu erzeugende Objekte können wieder verwendet werden (Pfandflaschen-Prinzip) Sparen von Ressourcen Entkoppelung der Objekt-Erzeugung vom Client Flexibilität / Limitierte Anzahl

25 Nachteile Ein verwendetes Objekt muss «aufgeräumt» werden kostet ebenfalls Zeit Objekt-Pool als Synchronisationspunkt Bottleneck Client muss ev. auf die Verfügbarkeit des nächsten freien Objekts warten Der Client sollte das Objekt möglichst rasch wieder zurückgeben Fehlerquelle Code wird komplexer Objekte können stale und damit für Client unbrauchbar werden z.b. Database-Connections

26 Verwendung ObjectPools sind von Vorteil wenn die Erzeugung der Objekte teuer ist. die Memory-Ressourcen knapp sind. die Clients die Objekte nur in einem gewissen Bereich (z.b. einem klaren Kontext/Bereich) benötigen (Socket-Schnittstelle / Ports) Sicherstellen der Objekt-Rückgabe. Ev. kann bei Bedarf (bei «grossem Andrang») die Anzahl Objekte erhöht werden. Ev. kann bei «Nichtbedarf» der Pool verkleinert werden um Ressourcen zu sparen.

27 Verweis auf andere Muster Verwandte Muster sind Singleton/Multiton (Pool aus einer oder n Instanzen) Prototyp: Erzeugen einer Instanz als Clone (exakte Kopie) eines existierenden Objektes.