Ich würde mal behaupten, dass das Factory Pattern eins der beliebtesten und gleichzeitig eins der am meisten missverstandenen Patterns ist. Das liegt sicher auch an oftmals irreführenden Beispielen.
Grob gesagt hat das Factory Pattern den Sinn, die Erstellung der betroffenen Objekte zu kapseln und zu abstrahieren, damit sich der verwendende Code nicht damit beschäftigen muss.
Warum will man die Erstellung von Objekten abstrahieren? Nun, meistens will man das nicht und dann ist das Pattern auch völlig fehl am Platz. Wenn die Factory eigentlich nichts abstrahiert bzw. unnötigerweise abstrahiert und sich in ihrer Verwendung nicht von einem direkten Konstruktoraufruf unterscheidet, dann bietet sie keinen Mehrwert:
Code:
abstract class User {}
class NormalUser extends User {}
class Admin extends User {}
abstract class UserFactory
{
public abstract function createUser();
}
class NormalUserFactory extends UserFactory
{
public function createUser()
{
return new NormalUser();
}
}
class AdminFactory extends UserFactory
{
public function createUser()
{
return new Admin();
}
}
class SomeClass
{
public function doStuff($user_type)
{
if ($user_type === 'admin')
{
$factory = new AdminFactory();
}
else
{
$factory = new NormalUserFactory();
}
$user = $factory->createUser();
}
}
Diese Factory könnte man sich z.B. völlig sparen, weil du damit nichts abstrahierst und es in diesem Fall vielleicht auch gar nicht nötig wäre. Wenn man sich in SomeClass nicht auf die konkrete Implementierung von User festlegen will, kann man z.B. auch einfach den User als Parameter in die Methode bekommen und der Aufrufer entscheidet, ob er einen Admin oder einen normalen User übergibt. In vielen falsch verwendeten Factories würde es eigentlich reichen, das erstellte Objekt selbst in die jeweilige Methode hereinzureichen, weil es eigentlich nur darum geht, die Implementierung des Objekts zu abstrahieren, aber nicht die Erstellung.
Eine Factory brauchst du wirklich nur dann, wenn du jederzeit ein Objekt, das eine bestimmte Schnittstelle implementiert,
erstellen können musst,
ohne den konkreten Typ zu kennen.
Wie könnte so ein Beispiel aussehen? Na ja, stellen wir uns mal vor, PHP wäre eine Systemsprache (ich weiß, lol) und wir würden ein betriebssystemunabhängiges Window Management implementieren (ja, das wirkt etwas komplex, aber Factories sind nun mal in simplen Systemen i.d.R. einfach nur unnötig):
Code:
abstract class Window
{
/* some generic window stuff */
public abstract function setTitle($title);
public abstract function show();
}
class LinuxWindow extends Window
{
/* linux-specific implementation */
}
class WindowsWindow extends Window
{
/* windows-specific implementation */
}
abstract class WindowFactory
{
public abstract function createWindow();
}
class LinuxWindowFactory extends WindowFactory
{
public function createWindow()
{
/* complex linux-specific code */
return new LinuxWindow(/* linux-specific parameters */);
}
}
class WindowsWindowFactory extends WindowFactory
{
public function createWindow()
{
/* complex windows-specific code */
return new WindowsWindow(/* windows-specific parameters */);
}
}
class WindowManager
{
private $wndfact;
private $all_windows;
public function __construct(WindowFactory $w)
{
$this->wndfact = $w;
}
/* window manager stuff */
public function spawnWindow($window_title)
{
$wnd = $this->wndfact->createWindow();
$wnd->setTitle($window_title);
/* some more complex init stuff */
$wnd->show();
$this->all_windows[] = $wnd;
return $wnd;
}
}
$window_factory = get_platform() === 'windows'
? new WindowsWindowFactory()
: new LinuxWindowFactory();
$window_manager = new WindowManager($window_factory);
/* do stuff with $window_manager */
Das Ganze ist natürlich stark vereinfacht, aber ich hoffe, das Prinzip wird klar. Der WindowManager ist eine komplexe Klasse, die alle Fenster verwaltet (d.h. sie aktualisiert, Events auslöst etc.). Dabei muss er auch Fenster erstellen können, was in der Methode spawnWindow passiert (es könnte aber auch einfach im Rahmen anderer Funktionalitäten nötig sein, neue Fenster zu erstellen, z.B. in einer Methode wie showMessageBox).
Nun willst du den WindowManager aber nicht für jedes Betriebssystem neu implementieren, wenn er eigentlich immer das gleiche macht und die einzige systemspezifische Eigenschaft das Erzeugen des Window-Objekts ist (weil eben für unterschiedliche Systeme unterschiedliche Daten und Systemaufrufe innerhalb des Windows verwendet werden).
Die Lösung ist nun eine Factory: Du abstrahierst die Erstellung von Fenstern weg, sodass der WindowManager seine Funktionalität auf die abstrakten Klassen Window und WindowFactory stützt. Wie die funktionieren und was die zurückgeben, ist ihm egal. Er macht seinen Job auf Basis der Schnittstellen, die die abstrakten Klassen bereitstellen. Dem WindowManager übergibst du dann einfach eine Factory deiner Wahl, die die korrekten Window-Objekte für einen bestimmten Kontext (z.B. je nach Betriebssystem) für den WindowManager erstellt. So musst du für jedes System nur Window und die WindowFactory implementieren, aber der WindowManager funktioniert immer gleich.
Das ist der Mehrwert einer korrekt eingesetzten Factory: Wenn Objekte auf unterschiedliche Weisen erstellt werden können/müssen, aber du diese Unterscheidungslogik nicht in deiner Klasse XY haben willst, dann brauchst du eine Factory, die du an XY übergibst.
Deine zweite Frage verstehe ich nicht wirklich.
