Dynamische Methodik und nicht-spezifische Rückgabe werte von Methoden

[Bratkartoffel]

Hi,

ich habe mir das Projekt nur kurz angeschaut, aber folgenden Input kann ich dir dazu liefern:

* Bitte verschiebe deine Packages in ein vernüftiges Basis-Package. Zum Beispiel "de.thorbenkuck.RegisterHandlerFW. Gleiches gilt auch für die "group" im gradle.
* Das Class-Path Scannen geht auch einfacher / schneller, kann dir den hier empfehlen: https://github.com/lukehutch/fast-classpath-scanner
* Ein "System.out" ist für eine Library ganz übel. Bitte verwende ein Logging-Framework wie zum Beispiel "slf4j"
* Deine Register:cloneObject() schluckt alle Exceptions und gibt nur "null" zurück. Baue eigene Exceptions und wirf die weiter. So hat der Benutzer der Library keine Ahnung, warum und dass überhaupt was nicht funktioniert.
* Vom "clone via Reflection" + Eigenentwicklung bin ich nicht begeistert. Da gibts schon (je nach Anwendungsfall) diverse Implementierungen: http://stackoverflow.com/a/2156367/1164913. Was passiert bei dir, wenn ein Modul ein Attribut auf sich selbst hat? => Was spricht dagegen, dass du als Library-Programmierer erwingst, dass die Module Serializable implementieren?

Wenn ich Zeit habe dann schau ich mir das gerne mal genauer an, mein Interesse besteht weiterhin

Grüsse,
BK

 

[StormCraftable]

Alles klar! Ich beschäftige mich jetzt erst seid ca. einem halben Jahr genauer mit Java.. Ich weiß noch nicht so genau, was die "do's and don'ts" sind..
Die System.out aufrufe sind nur, weil ich irgendwo eine Ausgabe brauchte
Und das mit Register:cloneObject() war genau das Problem, welches ich ein paar Posts vorher gefragt hatte
Ich bastle mal ein bisschen dran rum!

 

[StormCraftable]

Okay. Wie ich das sehe, habe ich 2 Möglichkeiten für cloneObject.
1. Ich nutze die alte Methode und sage, dass alle Klassen bestimmte Kriterien erfüllen müssen (schei*e).
2. Ich lasse die Klassen ein Interface implementieren, welches selbst Serializable implementiert (Wollte ich nicht machen...).
Gibt es eine Möglichkeit, eine Klasse, welche mit @RegisterModule annotiert ist, das Serializable-Interface implementieren zu lassen?

 

[StormCraftable]

Wie auf github zu sehen ist, löse ich es nach Möglichkeit 2..
Das sieht nicht ganz so schön aus, aber es funktioniert.
Wenn noch jemand eine Idee hat, wie man das mit der Annotation lösen kann (ich bin echt ein Fan davon, wie schlank und angenehm das damit aussieht), würde ich mich über einen Pull-Request sehr freuen!
Des weitern nutze ich jetzt den fast-classpath-scanner, wie vorgeschlagen.

 

[StormCraftable]

Im back!
Und es gab ein größeres Update! Also eig. nur 500 Zeilen mehr, aber es geht um das was unter der Haube ist.
Im Kern habe ich die DataOutputPipe jetzt von einem Singleton zu einem "Multiton" umgewandelt. Das heißt, nicht das klassische Multiton. Man kann die DataOutputPipe immer noch normal instanziieren. Es hat jetzt quasi zusätzlich die Möglichkeit angesprochen zu werden wie ein Multiton. Das heißt, man kann jetzt so viele DataOutputPipes haben, wie man möchte! Yay!
Der Kern des ganzen ist jetzt aber, dass die Klassen, die in eine DataOutputPipe sollen (also die mit dem Interface, bzw. der Anotation), nun auch ohne Default-Constructor instanziiert werden können!
Wie? Nicht so ganz einfach. Folgender Aufbau:
Wir habe eine DataOutputPipe und sagen ihr, lade die notwendigen Klassen. Aufgrund von SRP (https://de.wikipedia.org/wiki/Single-Responsibility-Prinzip) wird diese Aufgabe jetzt von einer anderen Klasse übernommen. Die ClassDependencyResolver-Klasse um genau zu sein. Diese scant aktuell auch noch, aber das soll auch ausgelagert werden. Dabei werden dann alle Konstruktoren einer Klasse, welche includiert werden soll gescannt. Gibt es einen Konstruktor mit der neuen Annotation @AutoResolve, so wird dieser versucht auf zu lösen und das über Constructor.newInstance() mit konkreten Parametern. Diese nimmt er aus der Instanz der DataOutputPipe! Das heißt, man kann manuell dependencies hinzufügen und die Abhängigkeiten werden intern aufgelöst!

Warum ich kein Framework dafür nutze: Ich wollte keine Abhängigkeit zu Frameworks aufbauen, die potentiell Probleme mit anderen Frameworks machen könnten.

Ach und Log4J ist jetzt includiert.

Pläne für die Zukunft: Ein Register nicht als stumpfen get-set-Container, sondern als Repository und Ausalgerung vom Logging.

Soll ich etwas hier von genauer erklären?

Mit freundlichsten Grüßen:
StormCraftable