Also schreibe ich ein Spiel und ich bin auf ein Rätsel gestoßen, wo ich glaube, Reflection könnte eine bessere Lösung sein. Aber da ich weiß, dass Reflection entmutigt ist und meine andere Lösung nicht so hübsch aussieht, dachte ich, ich würde hier fragen, was in diesem Szenario eigentlich eine bessere Idee ist.
Im Wesentlichen habe ich eine abstrakte Kartenklasse und werde mehrere Implementierungen davon haben. Ich habe einen Fall, wo ich einen Kartennamen bekommen habe und ein Objekt davon konstruieren muss, nur den Namen gegeben.
Ich weiß, ich könnte beides benutzen:
a) Reflexion und Verwendung forName und invoke. Es wird ein sehr kurzer Code sein, gut skalieren und leicht genug zu schreiben sein. Das heißt, es ist Reflektion, und ich bin dafür, es zu vermeiden, wenn ich es nicht besonders brauche.
b) Verwenden Sie ein Factory-Entwurfsmuster, und führen Sie anschließend eine umfassende bedingte Prüfung durch und rufen Sie die entsprechende Klasse basierend auf dem von mir angegebenen Namen auf. Es ist nicht schwierig zu schreiben, erfordert aber ständige Wartung und wird eine Weile dauern, um zu schreiben, und es wird nicht gut skalieren. Das heißt, es ist eine Nichtreflexionslösung.
Was ist die ideale Lösung? Verwende ich nur Reflection, weil es meinen Code schön und kurz hält?
Hier ist eine Alternative (nicht sicher, ob es die "ideale Lösung" wie du erwähnt hast, aber ich denke, es ist eine Überlegung wert): aufgezählte Typen. Es wird immer noch eine riesige Liste sein, aber vielleicht ein bisschen sauberer? Und Sie müssen sie alle irgendwo definieren.
Ein Beispiel dafür, was ich meine:
%Vor%Dann, wenn Sie einen Namen brauchen, tun Sie einfach:
%Vor% Dies setzt voraus, dass es sich bei den Karten um Singletons handelt, aber Sie könnten ebenso einfach die Methode getCard verwenden, um eine Fabriklogik zu erstellen, um eine neue zu erstellen.
Ich würde vorschlagen, ein Fabrikmuster zu verwenden und eine vorgefertigte Fabrik wie Spring zu verwenden, die Sie verwenden können, um dort Bohneninstanzen zu definieren, anstatt Ihre eigene Fabrik zu implementieren. Es wird einfacher skaliert, da Sie einfach mehr Bean-Typen entweder in XML oder mit annotiertem Java-Code definieren können. Stellen Sie nur sicher, dass Sie Nicht-Singleton-Beans verwenden, und jedes Mal, wenn Sie Ihre Spring Factory nach einer Bean eines Namens fragen, wird der Konstruktor korrekt aufgerufen. Es wird Ihnen sogar erlauben, gleichzeitig Dependency-Injektionen kostenlos durchzuführen.
Tags und Links java reflection factory