Viele generische Parameter sinnvoll? oder besser casten?

[-frank]

ich habe mehrere Klassen, zb AThing, BThing, CThing. ein Thing kann u.a. die Eigenschaften eines anderen Things (desselben Typs) übernehmen, wobei gemeldet wird, was geändert werden musste, um alle Eigenschaften zu übernehmen. der code in AThing könnte folgendermaßen aussehen:

public AThingChangeReport copySettings(AThing otherThing) {...}

und der in BThing so:

public BThingChangeReport copySettings(BThing otherThing) {...}

nun ist es so, dass die Things sehr viele Gemeinsamkeiten haben, auch die ChangeReports. Ich hab daher eine abstrakte Klasse Thing und eine weitere abstrakte Klasse ThingChangeReport. Nur die Dinge, die wirklich nur AThing betreffen, werden in AThing gecheckt und in den AThingChangeReport geschrieben. ich habe also eine abstrakte methode wie

public abstract void copyMoreSpecificSettings(Thing otherThing, ThingChangeReport) {...}

in dieser methode muss ich dann natürlich typüberprüfungen machen und casten.

okay und nun siehts so aus, dass ich noch ein paar weitere solcher methoden haben, die zuerst in der abstrakten klasse Thing etwas machen und der spezielle code wird dann eben in den subklassen abgearbeitet. es gibt auch noch weitere klassen à la AThingChangeReport, also solche, die mit dem jeweiligen typ in verbinbung stehen

public void setBox(AThingBox box);
public AThingBox getBox();

da der code aber (mit allgemeinen typen) in Thing steht, also:

public void setBox(ThingBox box);
public ThingBox getBox();

... entsteht dann viel unnötiger code in den implementierenden klassen.:

public void setBox(ThingBox box) {
    // check instance of AThingBox
    ..
    super.setBox(box);
}

public AThingBox getBox(); {
    return (AThingBox) super.getBox();
}

sind jetzt nur blöde beispiele. ich komme öfters in solche oder ähnliche situationen (was ähnliches findet sich zb hier: http://www.java-forum.org/de/viewtopic.php?t=52162&highlight=). wenn es nur sehr wenige solcher methoden gibt bzw. nur wenige things, dann denke ich meist nicht drüber nach. aber wenn nun zb jedes Thing 10 solcher methoden und ich habe 10 verschiedene thing klassen, dann hab ich schon 100 (unnötige) methoden oder aber ich habe überall im code viele casts (und eventuell typüberprüfungen). beides gefällt mir nicht, weshalb ich es mit generics probiert habe. das ganze wird dann aber extrem kompliziert:

 public abstract class Thing<T extends Thing, U extends ThingBox<T>, V extends ThingChangeReport<T>, ... {..}

das ganze funktioniert eigentlich toll! die abstrakte Thing-Klasse kann so selbst die richtigen typen returnieren, weiters brauche ich in den subtypen keine typüberprüfungen, weil Thing bereits die richtigen typen an die abstrakte methode weitergeben kann, es gibt keine casts, etc.
ABER es sieht IMO eben extrem unschön aus. speziell das "T extends Thing" übergebe ich ja eigentlich nur, damit Thing seinen eigenen speziellen Typ kennt (ging das irgendwie anders??) und die anderen Parameter wie ThingBox näher spezifiziert sind (also denselben generischen Thing-Typen haben müssen).

naja, ich weiß jetzt nicht wirklich, was ich tun soll. ich traue mir nicht wirklich zu, zu beurteilen wie gut/schlecht die generische lösung ist, auch im hinblick auf verständlichkeit/wartbarkeit des codes. eventuell nehme ich die generizität wieder raus und caste/überschreibe eben mehr...

bin aber auf jeden fall für alle anregungen dankbar. wie gesagt stellt sich mir dieses problem schon in mehreren varianten und ich überlege jedes mal wieder, wie es am besten zu lösen ist, ohne wirklich eine gute lösung zu finden (eventuell kann man es auch ganz anders machen?...)

 

[JPKI]

Das der Code dann unschön wird und komplizierter zu lesen ist, musst du nun einmal gegen das Schreiben der vielen "unnötigen" Methoden abwiegen.

Ich persönlich würde die Lösung mit Generics bevorzugen, weil sie mir wirklich viel Tipparbeit ersparen.

 

[Wildcard]

Visitor?

 

[-frank]

@JPKI: mal sehen. ich habe nochmal drüber nachgedacht. zumindest teilweise ist die generische struktur ja eh "versteckt" (also ich meine, dass man sich ja nicht drum kümmern muss, wenn man mit den konkreten klassen arbeitet). wirklich verstehen muss man das ganze nur, wenn man eine weitere konkrete klasse hinzufügt.

@wildcard:
ich habe mir das pattern angesehen, auch noch etwas gegooglet dazu. mir ist aber nicht klar, wie ich es auf mein problem umlegen soll. verwenden soll man das pattern zB wenn "an object stucture contains many classes of objects with differing interfaces and you want to perform operations on these objects that depend on their concrete classes.", weiters "the classes defining the object structure rarely change, ..". also teilweise trifft dies sicher zu. ich habe aber nicht diesen für visitor-pattern-beispiele scheinbar typischen baum, der traversiert werden muss. bei mir gehts meistens um operationen auf einzelnen objekten, wobei ich hier aber wie gesagt immer die richtigen typen brauche.

würdest du dir das nun so vorstellen?:

public class CopySettingsVisitor implements ThingVisitor {

    private Thing thing;

    // thing --> Thing dessen werte genommen werd und in andere Things kopiert.
    public CopySettingsVisitor(Thing thing) {
        // check thing not null
        ..        
        this.thing = thing;
    }

    private void copyGeneralSettings(Thing otherThhing) {
        //überprüfe ob otherthing und thing vom gleichen typ...
        ..
        otherThing.setSomeValue(this.thing.getSomeValue);
        ...
    }    

    public void visitAThing(Athing otherThing) {
        copyGeneralSettings(otherThing);
        
        otherThing.setSomeASpecificValue(this.thing.getSomeASpecificValue());
    }

    public void visitBThing...
}

jedes Thing hat ne Methode wie

public void accept(ThingVisitor visitor);

in AThing lautet der Code dieser Methode dann

visitor.visitAThing(this);

hmm, okay. also IMO ist das etwas komplizierter als in den beispielen, weil ich ein zweites Thing zum kopieren brauche, aber prinzipiell sieht das für mich aus als würde es durchaus sinn machen. was ich nun aber nicht verstehe, ist, wie ich das zb auf die simple box-setter/getter-methode anwenden kann. eventuell würde mir schon reichen, wenn du mir das codestück sagst, wie man von außen dann an die box (mit dem konkreten typ) kommt. brauche ich dann einen BoxGetterVisitor?

danke auf jeden fall euch beiden![/code]

 

[Tellerrand]

 public abstract class Thing<T extends Thing, U extends ThingBox<T>, V extends ThingChangeReport<T>, ... {..}

das ganze funktioniert eigentlich toll! die abstrakte Thing-Klasse kann so selbst die richtigen typen returnieren, weiters brauche ich in den subtypen keine typüberprüfungen, weil Thing bereits die richtigen typen an die abstrakte methode weitergeben kann, es gibt keine casts, etc.
ABER es sieht IMO eben extrem unschön aus. speziell das "T extends Thing" übergebe ich ja eigentlich nur, damit Thing seinen eigenen speziellen Typ kennt (ging das irgendwie anders??) und die anderen Parameter wie ThingBox näher spezifiziert sind (also denselben generischen Thing-Typen haben müssen).

Zum fettmarkierten:
Wieso musst du "U extends ThingBox<T>, V extends ThingChangeReport<T>" schreiben?
Werden überhaupt verschiedene Subklassen von ThingBox oder ThingChangeReport gebildet?


Pauschal würde ich sagen Generics sind die eleganteste Lösung.


EDIT:
Worauf ich hinaus will ist, wenn du "U extends ThingBox<T>" nur schreibst, damit "ThingBox näher spezifiziert ist (also denselben generischen Thing-Typen hat)", dann würde ich das streichen und in der Klasse Thing, anstatt U einfach ThingBox<T> verwenden.
Du brauchst das "U extends ThingBox<T>" in der Klasse Thing ja nur genau dann, wenn verschiedene Subklassen von ThingBox existieren.
Existieren keine Subklassen von ThingBox und du willst nur den generischen Typ exakt spezifizieren reicht ja folgendes:

public class Thing<T extend Thing> {

    public ThingBox<T> getBox() {
        return ThingBox<T> bli bla blub ....
    }
}

 

[-frank]

Zum fettmarkierten:
Wieso musst du "U extends ThingBox<T>, V extends ThingChangeReport<T>" schreiben?
Werden überhaupt verschiedene Subklassen von ThingBox oder ThingChangeReport gebildet?

ja. ein ThingChangeReport soll einerseits einen Verweis auf das Thing selbst haben. (ähnlich wie bei den ChangeEvents in Swing, die alle ne Source haben). getThing() (bzw. getSource()) soll den richtigen typen liefern, was mit generics kein problem ist. deswegen bekommt ThingChangeReport das T.
subklassen brauche, weil zB AThing mehrere A-spezifische Werte hat und im changereport auskunft über änderungen dieser werte gegeben werden soll.

 

[Wildcard]

@frank
kannst du bitte versuchen dein Problem auf einer weniger abstrakten Ebene zu schildern?
Weiterhin ist mir der Sinn der ThingBox derzeit noch verschlossen.
Ist das ein Versuch dein konkretes Problem zu lösen, oder ein direkter Teil deines Programms?

Versuch bitte dein eigentliches Problem verständlich darzulegen, ohne Annahmen über einen möglich Lösungsweg.
Ich denke dann fällt es leichter sich eine sinnvolle Strategy zu überlegen.
Das sage ich insbesondere deshalb, da du davon sprichst häufiger über gleichartige Probleme zu stolpern und genau hier kommen Design-Patterns ins Spiel.

 

[-frank]

@wildcard:
das mit den häufig gleichartigen problemen bezog sich besonders auf eine struktur mit einer abstrakten basisklasse und mehreren konkreten implementierungen, wo die konkreten klassen konkrete(re) typen returnieren sollen bzw. eben mit spezielleren typen arbeiten. hier kann man mit generics schon einiges machen, auch ohne dass es kompliziert wird (dürfte also nicht so schlecht sein).

die oben erwähnte, doch recht komplizierte "generische struktur" (ist das die offizielle bezeichnung? generische strukur? oder typparameter-struktur? generische signatur? ..) kommt mir zum glück nicht ständig unter

folgendes beispiel ist nicht exakt meine problemestellung, aber ich hoffe konkret genug:
ich habe Mensch-Objekte, welche Menschen in einer Schule beschreiben. Jeder Mensch hat Name, Adresse und Geburtsdatum. Schüler (extends Mensch) haben auch einen Notendurchschnitt. Lehrer haben Unterrichtsfächer und Dienstjahre, der Schulleiter muss zb eine Handynummer haben.

nun gibt es eine zweite darauf aufbauende strukur ErweiterterMensch. erweiterte menschen haben zum beispiel biologische informationen (größe, augenfarbe, gewicht), aber auch hobbies. ein ErweiterterSchüler hat zB eine Liste von Fächern, die er belegt hat. Ein erweiterter Lehrer hat Informationen zu Zusatzausbildungen, etc.

ErwMenschen bekommen im Konstruktor ein Mensch-Objekt, ErwSchüler aber natürlich SchülerObjekte, etc.

ErwMenschen können ebenso ihr zugehöriges Mensch-Objekt liefern (bzw. ein solches erzeugen und returnieren).

(wie gesagt ist das jetzt nicht exakt mein problem, aber so ähnlich siehts aus. Zu Mensch, Schüler etc. gibt es übrigens jeweils Interface + Implementierung. Gemeinsame Methoden finden sich in AbstractMensch. diese Dinge existieren also alle bereits, werden in anderen Programmteilen auch verwendet)

Ein Teil dieser Daten soll nun auch grafisch in einer GUI dargestellt werden. --> MenschModel. die Daten eines MenschModel sollen über ein ErwMensch-Objekt aktualisiert werden (bzw. so ist es bereits).
Natürlich muss hier wieder ein SchülerModel mit einem ErweitertenSchüler aktualisiert werden, etc.

bei so einer Aktualisierung soll die update-Methode einen Report liefern, welche Daten aktualisiert wurden. Dazu gibt es eine Aktualisierungsreport-Klasse (bzw. einen ChangeEvent). Die Daten, die nur Schüler betreffen, finden sich wieder in einer konkreten Klasse SchülerAktualisierungsreport.

1-2 sachen gäbs dann noch. aber wenn wir mal dabei bleiben, dann komme ich mittels generics zu folgender struktur für die models:

(Edit: kleine korrektur

class MenschModel<T extends Mensch, U extends ErweiterterMensch<T>,
V extends MenschModel<T, U, V, W>, W extends Aktualisierungsreport<V>>

--> sp kann zb ein SchülerModel in einer Methode getMensch() ein Schüler-Objekt liefern, und eine update() Methode kann als Argument nur ErwSchüler-Objekte akzeptieren und den konkreten SchülerAktReport zurückliefern.

prinzipiell funktioniert jetzt so alles und ich konnte etlichen Code entfernen (und es kommt da schon einiges zusammen, das beispiel einfach noch ein wenig aufgeblasener vorstellen ).
aber wie gesagt war/bin ich mir nicht sicher, ob man das so macht bzw. machen soll, was dagegen spricht, etc. (und eben auch nicht, wie du hier das visitor-pattern anwenden würdest). weiters sind diese selfbounded-generics wohl keine ganz triviale sache (hab zb die diskussion hier gefunden http://www.artima.com/forums/flat.jsp?forum=106&thread=136394&start=0&msRange=15).

 

[Wildcard]

Ist nun wirklich ein Anwendungsfall der mir auf diese Weise noch nie (noch nicht mal ähnlich) unterkam.
Hast du schonmal darüber nachgedacht dir die Bean Eigenschaften zu nutze zu machen und einfach Reflection zu benutzen.
Zum Beispiel beim Kopieren von Werten:
get Methoden vom Quell Objekt holen und mit den set Methoden des Ziel Objekts vergleichen.
Bei einem match wird der Wert von get in die set Methode des Gegenparts übergeben.

 

[-frank]

Ist nun wirklich ein Anwendungsfall der mir auf diese Weise noch nie (noch nicht mal ähnlich) unterkam.

deutet das deiner meinung nach daraufhin, dass hier grundsätzliche grobe design/denkfehler begangen wurden (dass es überhaupt soweit kam) oder ist es einfach nur ein sehr spezielle, ungewöhnliche situation, die aber (In dieser speziellen situation) durchaus so gelöst werden kann?

Hast du schonmal darüber nachgedacht dir die Bean Eigenschaften zu nutze zu machen und einfach Reflection zu benutzen.

nicht wirklich. ich setze reflection zwar schon ein, um zb mittels einer Liste von Schüler-Objekten eine Liste von erweiterten Schülern zu kreieren (--> Konstruktor suchen, instanzieren), aber ansonsten nicht. dein beispiel mit dem kopieren von werten könnte bei mir durchaus gehen. weiß aber nicht, ob ich alles so lösen könnte (hab auch sehr wenig erfahrung mit reflection, müsste mich da mal eingehender damit beschäftigen)

 

[Wildcard]

deutet das deiner meinung nach daraufhin, dass hier grundsätzliche grobe design/denkfehler begangen wurden (dass es überhaupt soweit kam) oder ist es einfach nur ein sehr spezielle, ungewöhnliche situation, die aber (In dieser speziellen situation) durchaus so gelöst werden kann?

Dazu will und kann ich kein Aussage treffen. Lediglich ein wertungsfreier Hinweise meinerseits das ich ein derartige Konstellation noch nicht hatte.
Konkret fällt mir keine Situation ein in der häufig Werte von Elter-Kind-Schwester Klassen kopiert werden müssten, oder warum ein solcher Report nicht einfach über eine Observer Schnittstelle realisiert wird, aber wie gesagt, ich kenne deinen Anwendungsfall nicht.

nicht wirklich. ich setze reflection zwar schon ein, um zb mittels einer Liste von Schüler-Objekten eine Liste von erweiterten Schülern zu kreieren (--> Konstruktor suchen, instanzieren), aber ansonsten nicht. dein beispiel mit dem kopieren von werten könnte bei mir durchaus gehen. weiß aber nicht, ob ich alles so lösen könnte (hab auch sehr wenig erfahrung mit reflection, müsste mich da mal eingehender damit beschäftigen)

Ich würde es zumindest in Erwägung ziehen bevor du ein Generics Monster bastelst.
Der Reflection Ansatz ist zwar vermutlich mit recht wenig Code zu erledigen, aber auch nicht ohne Nachteile und störend beim Debuggen und Refactoring. Die Entscheidung musst du treffen...