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

Haltet ihr so etwas für Sinnvoll?

  • Anzahl der Umfrageteilnehmer
    2
Ich habe ein tatsächlich hartnäckiges Problem. Und zwar muss ich Objekte "clonen" und das zur Laufzeit, ohne Copy-Konstruktor.
Das Problem manifestiert sich wie folgt:
Ich nutze hier das selbe Beispiel, wie vorher auch.
Java: 
        RegisterHandler registerHandler = RegisterHandler.getInstance();
        RegisterHandler.setScanRootPackage("test");

        RegisterID id = registerHandler.pullNewRegister();

        RegisterHandler.getInstance().bindRegister("1" , id);

        Tester tester = registerHandler.getRegisterForId(id).fetchAndGetModuleFromPipe(Tester.class.getName());
        Tester2 tester2 = registerHandler.getRegisterForId(id).fetchAndGetModuleFromPipe(Tester2.class.getName());

        C c = RegisterHandler.getInstance().getRegisterForId("1").pullAndGetModuleFromPipe(C.class.getName());

        RegisterHandler.getInstance().getRegisterForId("1").pushModuleToRegister("c", c);

        c.higher();

        int longer = 0;

        while(longer < 4) {

            tester.run();
            tester2.run();

            longer++;
        }
Meiner Idee nach, dürfte die Zeile:
Java: 
c.higher();
keine Auswirkung auf die beiden Tester haben, da ich nachdem ich c.higher() aufrufe, das neue Objekt nicht mehr pushe.
Ich habe das auf die Methodik zurück verfolgt, nach der wir die Module (Objekte) aus den Registern bekommen. Da wir in jedem Fall das Gleiche Objekt zurück geben, denkt der Compiler bei jedem Aufruf eines Objektes, das wir so bekommen haben, es sei das Selbe und spreche die gleichen Physikalischen Register an. Das soll nicht sein. Deswegen meine Frage:
Ist es möglich, ein Objekt zur Laufzeit zu Clonen, ohne einen Copy-Konstruktor zu besitzen?
Das Problem ist, dass die .clone() Methode von Objekten protected ist, ich aber auf keinen Fall die Klasse Klonen kann, da ich ansonsten den ganzen Sinn des RegisterHandlers negiere.
Ist das möglich?
Bitte um Rückmeldung!
 
Abermals habe ich auch das Problem gelöst. Ich habe einfach folgende Methode zu dem Register hinzugefügt:
Java: 
public synchronized  Object cloneObject(Object object) {
  try{
  Object clone = object.getClass().newInstance();
  for (Field field : object.getClass().getDeclaredFields()) {
  field.setAccessible(true);
  if(field.get(object) == null || Modifier.isFinal(field.getModifiers())){
  continue;
  }
  if(field.getType().isPrimitive() || field.getType().equals(String.class)
  || field.getType().getSuperclass().equals(Number.class)
  || field.getType().equals(Boolean.class)){
  field.set(clone, field.get(object));
  }else{
  Object childObj = field.get(object);
  if(childObj == object){
  field.set(clone, clone);
  }else{
  field.set(clone, cloneObject(field.get(object)));
  }
  }
  }
  return clone;
  }catch(Exception e){
  return null;
  }
  }
Jetzt returned die Methode "pullModule" lediglich cloneObject(moduleContainerList.get(className));
Leute, jetzt mal wirklich, interresiert das hier keinen? Ist das alles kacke? Ist das eigentlich schon gelöst und deswegen antwortet keiner?
Ich meine, selbst wenn das alles kacke ist, könntet ihr mir wenigstens das als Feedback geben!
 
Ich setzte jetzt ne Dead-line. Wenn hier innerhalb der nächsten, keine Ahnung, Woche kein Feedback bekomme, gehe ich davon aus, dass das Thema "gelöst" und damit geschlossen ist.
 
Hi StormCraftable,

bitte nicht aufhören, ich finds super spannend, vor allem wie sichs so entwickelt :)
Ich bin selber leider bisher nicht mit Spring o.ä. in Verbindung geraten, daher kann ich dir leider auch nicht sagen, inwieweit du etwas realisierst, das es evtl. schon gibt.

Und dass sonst keiner was dazu sagt liegt wahrscheinlich daran, dass du ein sehr spezielles Thema behandelst und nichts ganz allgemeines. Das macht es aber nicht weniger interessant ;)

Viele Grüße
Daniel
 
Okay. Also, für jeden den Spring nichts sagt, Spring ist ein Framework für "Dependency Injection". Das ist kein böses oder gar ausgedachtes Wort, o.ä. sondern ein ziemlich nützliches Mittel um Zugehörigkeiten vom "Master-Slave-Prinzip" unter Kontrolle zu haben. Google hilft da sehr weiter.
Das Framework hier, das "Register-Handler Framework" (RHF) vereint mehrere Prinzipien. Zum einen Dependency Injection und "Singleton-Pattern" ohne die direkte Nutzung vom Singleton-Pattern und etwas, dass ich das Register-Pattern nenne. Die Idee, dass Instanzen zu Registern gehören und nicht zu Prozeduren. Das sorgt für kontrollierte Instanz-Zugehörigkeiten ohne dass Prozeduren Instanzen teilen müssen.

Vorteile, die mir so schnell einfallen wären:
- leichteres Debugging
- Erhöhte Wiederverwendbarkeit in Modular aufgebauten Programmen.
Nachteile:
- Mehr Code und kompliziertere Instantiierungen

Außerdem ist es super für das MVP(Model-View-Presenter)-Pattern. Die Idee von MVP ist es, die konkrete "Sicht" und die Daten für die Sicht zu trennen und durch "Presenter" zu vereinen. Der View kennt den Presenter und der Presenter kennt die Model. Auch hier hilft Google.
Das RHF ist dabei ein vollwertiger Presenter. Mehrere View-Instanzen können nämlich hier gleiche Instanzen von Objekten nutzen, ohne dass sie diese Übergeben müssen. Wir machen also konkreten Gebrauch von dem Presenter. Ein konkretes Beispiel wäre hier sowas wie:
Fenster (Gui, also der View) fragt RegisterHandler (den Presenter) nach Nutzernamen (den Model). Der Holt sich aus dem Register das Model aller Nutzernamen und kann diese an mehrere Fenster geben. Auch wenn sich hier etwas verändert, kann das ganz einfach jeder View erneut übernehmen, bzw muss es nicht einmal, nutzt er das entsprechende (also ein bestimmtes) Register nutzt.

Ist das so verständlicher? Oder habe ich jetzt noch mehr komische Begriffe in den Raum geworfen, was mehr Verwirrung stiftet als es aufklärt?
Etwas schnelleres Feedback wäre wirklich cool..
 
Hi,

von mir aus kannst du hier gerne weiterbauen, bzw. uns auf dem Laufenden halten wo du stehst, was das Ding inzwischen kann oder wo du Probleme hast. Ich verfolge den Thread (bisher passiv) weil ich das Thema interessant und deinen Ansatz gut finde. Deine Einführung gerade eben in das Thema fand ich sehr gut, danke hierfür. Mein erster Gedanke bei dem Thema war eh "Der baut Spring nach", erst langsam habe ich erkannt dass dem nicht so ist. Dein letzter Post hat hier auch sehr gut geholfen, gut dass hier jemand spring erwähnt hat.

Zu einer deiner Fragen weiter oben:
Ist es möglich, ein Objekt zur Laufzeit zu Clonen, ohne einen Copy-Konstruktor zu besitzen?

Ja, ich würde hier aber nicht per Reflection die Daten kopieren. In deinem Fall wird der Konstruktur der neuen Klasse durchlaufen, was u. U. zu unerwarteten Verhalten, Exceptions oder sonst was führen kann. Da du ein Framework zur Verfügung stellst weisst du ja nicht, was die anderen damit machen wollen. Ich würde hier ganz dreckig auf sun.misc.Unsafe setzen: http://howtodoinjava.com/core-java/related-concepts/usage-of-class-sun-misc-unsafe/

Grüsse,
BK
 
Hi,

erstmal danke für die super Erklärung!

Weil @Bratkartoffel es jetzt nochmal erwähnt hat, ich hab mir für deep copies mal eine Methode geschrieben, die mit Streams arbeitet...ist nur ewig her. Zur Performance im Vergleich zu der anderen Methode und ob das jetzt eher quick and dirty ist kann ich nichts sagen, evtl. ist sun.misc.Unsafe um einiges besser, kannte ich aber bisher nicht.

Ich schreib dir mal in etwa, wie der Code damals aussah:

Java: 
public <T> T cloneObject(T object, Class<T> type) throws Exception {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    ObjectOutputStream oos = new ObjectOutputStream(baos);
    oos.writeObject(object);
    ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
    ObjectInputStream ois = new ObjectInputStream(bais);
    return type.cast(ois.readObject());
}

Die Objekte müssen dann aber Serializable implementieren!

Viele Grüße
Daniel
 
Sorry das sich mich länger nicht gemeldet habe. Ich habe grade etwas Stress in der Uni..

@Improof
Also ich kann nicht erwarten, dass jede Klasse Serializable implementiert. Außer es gibt ne Reflection Möglichkeit das zur Laufzeit zu implementieren, was Probleme verursachen könnte.

@Bratkartoffel
Ich habe mir das Unsafe mal genauer angeschaut. Ich weiß nur nicht in wie weit das helfen kann.
Das Problem ist, dass ich sowieso davon ausgehe, dass die Konstruktoren vernünftig aufrufbar sind. Ansonsten könnten die Klassen nicht in der DataOutputPipe instantiiert werden.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück