1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

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

Dieses Thema im Forum "Enterprise Java (JEE, J2EE, Spring & Co.)" wurde erstellt von StormCraftable, 17. Mai 2016.

?

Haltet ihr so etwas für Sinnvoll?

  1. Ja

    50,0%
  2. Nein

    50,0%
  1. Bratkartoffel

    Bratkartoffel gebratene Kartoffel Premium-User

    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
     
    Zuletzt bearbeitet: 5. Oktober 2016
  2. StormCraftable

    StormCraftable Grünschnabel

    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 :oops:
    Und das mit Register:cloneObject() war genau das Problem, welches ich ein paar Posts vorher gefragt hatte :D
    Ich bastle mal ein bisschen dran rum!
     
  3. StormCraftable

    StormCraftable Grünschnabel

    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?
     
  4. StormCraftable

    StormCraftable Grünschnabel

    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.
     
  5. StormCraftable

    StormCraftable Grünschnabel

    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
     
Die Seite wird geladen...