![]() |
AW: Lose Funktionen oder als Funktion in Klasse
Zitat:
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. |
AW: Lose Funktionen oder als Funktion in Klasse
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:44 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz