Wenn es eine Factory ist, dann nenn es doch auch im Code so 😉
TSoftwareApps -> TAppFactory
TAppleApps -> TAppFactoryApple
TOfficeApps -> TAppFactoryMicrosoft
Das Beispiel mit dem Office-Programmen kommt mir bekannt vor.
Du bist wirklich ein Freund von enums. Mein persönlicher Geschmack wäre es nicht. Für mich ist es noch zu früh am morgen, aber spontan denke ich dass man mit einem
Code:
TAppFactory
------------
+ createCalculation(): TSoftwareApp
+ createPresentation(): TSoftwareApp
(...)
besser fährt als mit
Code:
TAppFactory
----------
+ createApp(enum TAppType): TSoftwareApp
Grade wenn man beispielsweise von deinem
TAppleApps
oder
TOfficeApps
weitere Unterklassen bilden würde (z.B.
TOfficeEvaluationApps
das nur Demo-Versionen liefert) müsste man die Case-Statements aus der Überklasse mitschleppen, kopieren, abändern. Fehleranfällig wenn da später geändert wird. Hat man einzelne Methoden für jeden Typ hat man das Problem nicht.
Bzgl. Testbarkeit würde ich auch in der Anwendungsklasse TAppStore davon abrücken hier ein enum zu geben, sich lokal eine in
TAppStore.Create(..)
hartverdrahtete Factory zu erstellen. Gib ihm nicht ein Enum, gib ihm die fertige Factory.