Zitat:
Zitat von AmicaNoctis
Das ist aber eine derart versteckte und feste Abhängigkeit, dass es dem Singleton Antipattern in nichts nachsteht und imho noch schlimmer ist, als der Ansatz des TO. Seiner unterstützt dabei wenigstens noch Legacy- und native Klassen.
|
Die Abhängigkeit steckt hier:
Zitat:
vom TO:
Die Werte der Parameter ergibt sich vorher durch einige Daten aus einer Config.
|
Ich frage nur, ob die Parameter wirklich im Konstruktor gebraucht werden. Sind sie wirklich notwendig, um das Objekt in den Initialzustand zu versetzen?
Von nativen Klassen sehe ich hier nichts - der TO inkludiert fleißigst.
Legay-Klassen sind das sicher auch nicht. Falls doch, könnte er sich Wrapper erzeugen ... ach was das führt doch schon wieder zu weit. Bleiben wir bei dem was wir wissen: Der TO bastelt so eine Art Autoloader und scheinbar braucht bei ihm jeder Ctor spezifische Parameter, die er in der App-Config abgelegt hat, was nur geht, weil sie schon zur Programmierzeit feststehen.
Wenn man die grunsätzlichen Fehler ausmärzt, sehe ich hier nichts, was über die normale Anwendung eines Autoloaders hinausgeht und für einen Autoloader braucht man i.d.R. keine Reflection.