Copy-Constructor aufrufen - Wie ???

[pocketom]

Kniffliges Problem:

Ich habe ein mehrstufiges Klassenmodell:

1. Die Basisklasse [c]AbstractExchangeableBusinessObject[/c] (autogenerated by JAXB, wird jedesmal überschrieben)
1.1 Die Implementation [c]ExchangeableBusinessObject extends AbstractExchangeableBusinessObject[/c], beinhaltet einen Copy-Contructor (quasi stellvertretend für AbstractExchangeableBusinessObject) welchen ich aufrufen möchte

2. Die abstrakte Klasse [c]AbstractMyClass extends ExchangeableBusinessObject[/c] (autogenerated by JAXB, wird jedesmal überschrieben), hier kann ich also keinen Copy-Constructor implementieren
2.1 Die Implementation [c]MyClass extends AbstractMyClass[/c], beinhaltet einen Copy-Constructor (stellvertretend für AbstractMyClass). Problem: Wie rufe ich nun von dieser Klasse aus den (Copy)Konstruktor von 1.1 ExchangeableBusinessObject auf ??? [c]super(myClass)[/c] ruft den (nicht vorhandenen) Copy-Construktor von AbstractMyClass, ich möchte jedoch noch eine "Ebene" tiefer...

Versucht hab ich es an dieser Stelle mit Reflection, derer ich zugegeben aber nicht all zu mächtig bin:
Mit [c]this.getClass().getSuperclass().getSuperclass().getConstructors()[0].???[/c] komme ich denke ich zumindest schonmal an den (bzw. im Beispiel einen beliebigen) Constructor ran. Nur wie übergebe ich dem jetzt das zu kopierende Objekt (quasi analog zu super(myCopyObject)) ???

Zur Ergänzung:
Die abstrakten Klassen definieren einfach nur Felder so wie sie über ein XML Schema definiert wurden. JAXB generiert aber keine Konstruktoren bzw. Copy-Constructoren, sondern nur simple Datenklassen mit Gettern/Settern. Die abstrakten Klassen werden immer wieder überschrieben sobald sich das Datenmodell des XML Schemas ändert. Hier können also keine Methoden implementiert werden. Die abstrakten Klassen können vom Developer nicht angefasst werden und sind tabu.


[EDIT] Es gibt seit kurzem eine mögliche Lösung cc-xjc. Leider läuft das Plugin bei mir derzeit noch nicht mit diesem XML Schema (crashed bei Listen). Bin also weiterhin an einer Lösung mittels Reflection o.Ä. interessiert.

 

[Metacoder]

Möglich, dass Du das mit Reflection hin bekommst (wobei ich Dir mangels Relfection-Know-How dabei nicht helfen kann).
Wenn Du allerdings das Design etwas änderst, sollte es auch ohne funktionieren.
Du könntest z.B. statt Vererbung (MyClass extends JAXBClass) mit Komposition arbeiten.
MyClass hat also eine Referenz auf eine JAXBClass-Instanz. Da die JAXBClass sowieso nur ein Datencontainer ist, könntest Du im CopyConstructor einfach die Referenz an das neue MyClass-Objekt übergeben.

 

[SlaterB]

wenn der Konstruktor

pulic ExchangeableBusinessObject(ExchangeableBusinessObject other) {
init(other);
}

lautet mit

protected void init(ExchangeableBusinessObject other) {
..
}

dann könnten Konstrutoren von Subklassen auch
init(other)
oder
super.init(other)
aufrufen

Methoden werden 'besser' vererbt

 

[pocketom]

@Metacoder
Das Design liesse sich mittlerweile nur noch mit viel Aufwand ändern. Ausserdem sind wir damit ansonsten sehr zufrieden, es erlaubt eine strikte Trennung von Datenstruktur und Methoden. In der ersten Version dieses BO-Modells wurde viel mit Komposition gearbeitet, was leider zu sehr komplexen und of unüberschaubaren Objekten führte (myObject.getOtherObject.getAnotherObject.setSomething()...). Wir schätzen mittlerweile die Restriktionen die sich automatisch durch Vererbung ergeben, so wird vorher einfach schon im Designstorming besser nachgedacht. Komposition setzen wir nur dann ein wenn sich ein Business Object auch in der Realität aus mehreren Entitäten zusammensetzt.

@SlaterB
Über die Einführung einer copy Methode haben wir auch bereits nachgedacht und beinahe schon umgesetzt.


Da wir zusammen mit dem Developer von cc-xjc noch gestern Abend die Bugs beheben konnten ist das alles nun hinfällig da die generierte Lösung die Elegantere ist und vor allem jede Menge Zeit spart.

-> cc-xjc-1.0.1dist-bin.zip