- Die Software ist für eine Maschine. Schon, aber nun hat die Maschine plötzlich meherer Einheite die man steuern muss.
- Orientation? Nun will man die erste Seite quer die anderen längs
Richtig, und wenn es sich mal ändert, dann muss man das halt mit ändern.
Die Änderung geht aber geordnet innerhalb einer Klasse aus meiner Sicht etwas einfacher als bei losen, verstreuten Funktionen.
So gibt es viele "Einheiten" in der Software, welche man über Jahrzehnte nicht anfassen muss.
So eben auch "Device-Orientation", was dann verschiedene Settings unter Portrait und Landscape kapselt.
Das ist z.B. bei mir ein TOrientation-Singleton, für meine Single-Display Projekte, für Tablets und Phones.
Jetzt kommt neuerdings noch "FlipDisplay" und ein rundes "Watch-Display" dazu, das muss halt bei Bedarf erweitert werden,
bleibt aber meiner Meinung immer noch schön unter einem Orientation-Singleton.
Du hast Recht, gibt es auf einmal 5 Device-Displays oder ein ansteckbares USB-Display, dann muss das entsprechend erweitert werden.
Dann verwaltet das Singleton halt auch dynamisch zu mountende USB-Display, es ist aber immer noch ein TDisplays Singleton für mich.
Kann man anders machen, muss man aber nicht.
Ich weiß jedenfalls, dass dieses Singleton wieder Jahrzehnte Bestand haben wird.
Der Vorteil, den ich speziell in diesem Fall sehe ist, dass die Domain "Displays" ein Singleton bleibt, egal wie viele und welche Displays ich noch dazu baue.
Aus meiner Sicht hängen alle Displays eben logisch zusammen und deshalb macht EIN Singleton für mich da immer noch Sinn.
Ein zentraler Verwalter für alle Displays, der könnte verschiedene Funktionen übernehmen.
Das kann er nicht, wenn alle Displays nur separat gesteuert werden.
Zumal die Displays in einer Session nicht tausendmal erzeugt und zerstört werden müssen.
Ok, ist aber meine Philosophie zu dem Thema, generell versuche ich auch Singletons zu vermeiden.
Insbesondere aber bei Hardware-nahen System setze ich das aus o.g. Gründen gerne ein.