Objektorientierte Programmierung: Teil 3 – Einzigartige Registrierung
Der Begriff der objektorientierten Programmierung (kurz OOP) existiert schon eine ganze Weile. Wer zuvor prozedural programmiert hat, erwischt sich beim Übergang zu OOP öfter dabei, wie er die früheren Funktionen einfach mit einer Klasse umgibt und dies als objektorientierte Programmierung verkauft. Die Artikelreihe soll an einem einfachen Beispiel zeigen, was man in so einem Fall besser machen könnte.
Hinweis: Bevor man im Artikel fortfährt, sollte man sich die vorherigen Teile der Reihe durchgelesen haben. Alle Artikel dieses Workshops finden Sie in der Übersicht.
Ganz allein auf der Welt
Im letzten Teil wurde die StrategyFactory über statische Methoden angesprochen. Prinzipiell ist das nicht falsch. Hierfür gibt es aber auch ein Entwurfsmuster, was dafür Sorge trägt, dass es im Programmablauf nur eine einzige Instanz einer Klasse gibt: das Singleton.
Design
Das Singleton-Entwurfsmuster lässt sich sehr einfach umsetzen. Hierzu ist es nur wichtig, dass der Konstruktor der StrategyFactory privat wird. Manch einer wird sich fragen, wer dann überhaupt noch die Klasse instanziieren darf. Ganz einfach: die Klasse selbst. Über die statische Methode getInstance wird dann der Zugriff auf die als Attribut gehaltene statische Instanz gewährt.
){kind=small}
Dominik Wagenführ
Die StrategyFactory als Singleton
Klassenaufteilung
An den CRC-Karten hat sich zum letzten Teil nichts geändert, weswegen diese hier nicht noch einmal extra dargestellt werden sollen.
Abhängigkeiten
Auch an den Abhängigkeiten hat sich zum letzten Teil nichts geändert.
Vor- und Nachteile
Es bestehen weiterhin die gleichen Vor- und Nachteile wie im letzten Teil. Das heißt, Erweiterbarkeit und Wartbarkeit sind im aktuellen Zustand sehr gut. Schlecht ist nach wie vor, dass die Fabrik jedes Mal im Code angepasst werden muss, wenn eine neue Strategie hinzukommt.
Was ist der Vorteil des Singletons? Es ist sehr klein, aber es wird sichergestellt, dass es nur eine Instanz des Objektes gibt. Natürlich hätte man dies auch mittels einer statischen Methode und eines privaten Konstruktors der vorhergehenden Lösung erreichen können. Dann hat man aber keine Kontrolle darüber, wann die Objekte, die die Fabrik benötigt, erstellt werden. Mit dem Singleton ist dies sichergestellt.
Man sollte sich aber über die Bedeutung des Singletons klar werden. Selbst, wenn es zwei parallel stattfindende Spiele geben sollte (also Instanzen von Game), nutzen diese beiden die gleiche StrategyFactory.
Aufpassen muss man in diesem Kontext auch auf Threadsicherheit. Wenn es möglich ist, dass die getInstance-Methode parallel aus zwei Threads gerufen werden kann, muss diese so abgesichert werden, dass dennoch nur eine Instanz generiert wird. Ansonsten hat man plötzlich zwei Objekte des Singleton, mit denen gearbeitet wird.
Implementierung
In C++ lässt sich das Singleton-Pattern auf mehrere Arten umsetzen. In der Beispielimplementierung wurde die einfache Methode gewählt. Diese ist aber nicht threadsicher, sodass es, wenn es mehrere Threads geben würde, zwei Instanzen der Fabrik zur gleichen Zeit geben könnte.
Die C++-Implementierung kann als Archiv heruntergeladen werden: oop5-beispiel.tar.gz.
