Vererbung, Generizität und Collections.

[-frank]

Ich habe eine Problem mit Vererbung, Generizität und Collections. ich verstehe die grundproblematik, also zb warum man eine List<SomeObject> nicht auf List<Object> casten kann. ich verstehe auch das Prinzip, dass ein Untertyp einer Klasse überall verwendet werden können soll, wo der Obertyp erlaubt ist. und das ist es da eben probleme gibt, weil der compiler die korrektheit nicht garantieren kann, etc.

was mir oft nicht klar ist, ist, wie man dieses problem am besten umgeht

ich habe eine Klasse TableInfo, die Informationen wie die Größe, das Gewicht, etc. eines Tisches kapselt + ein paar Methoden anbieten, um damit zu arbeiten. Die TableInfo wird von einigen Klassen verwendet. diese brauchen nicht mehr Informationen/Methoden, als TableInfo bietet. passt also so wie es ist.
An einer Steller aber reicht TableInfo nicht aus. Dort ist zb auch die Farbe oder die Holzart des Tisches von Bedeutung. Ich brauche aber weiterhin alle Infos+Methoden, die schon TableInfo bereitstellt. Für mich erscheint es nun logisch, TableInfo zu erweitern: also zb TableMoreInfo extends TableInfo.
bis hierhin gibts kein problem.

nun hat ein Tisch aber noch eine Liste von Dingen, die sich auf ihm befinden (Stifte, Bücher, etc.) und auch über diese Dinge gibt es Information
--> List<ThingInfo>
das große problem ist nun, dass ein TableMoreInfo Objekt auch eine List<ThingMoreInfo> benötigt.

ich frage mich nun, wie man sowas am besten löst. auf die vererbung zwischen TableInfo und TableMoreInfo will ich nicht verzichten, da ich den gesamten Code dann rüberkopieren müsste (und bei jeder Änderung an beiden Stellen ändern). eine überlegung war, die ThingMoreInfo objekte in die List<ThingInfo> zu schreiben. und beim Zugriff auf Elemente dieser Liste von TableMoreInfo aus einfach alle Elemente auf ThingMoreInfo zu casten. das problem, dass ich dann überall im code sehr viele casts hätte. was ich dann probiert habe, ist, einfach Methoden anzubieten, die aus der List<ThingInfo> von TableInfo eine List<ThingMoreInfo> erzeugen. (mit casts) und diese dann anbieten. das klappt eigentlich ganz gut und es sind fast alle casts weg. leider hat das aber natürlich den nachteil, dass es sich nicht mehr um die originalliste handelt. bei änderungen am original, ändert sich die kopie nicht.
meine nächste variante wären zwei listen, also die aus TableInfo plus eine weitere in TableMoreInfo und diese dann immer am selben Stand halten. damit hätte ich zwei eigentlich komplett idente liste, nur eben unterschiedlich typisierte list-referenzen. naja, auch nicht schön.

gibts für sowas ein designpattern bzw. ne patentlösung, wie es am besten gemacht wird?

danke schon mal!

 

[Hilefoks]

Irgendwie verstehe ich deine Frage nicht recht... ich veruche es dennoch mal....

ich verstehe auch das Prinzip, dass ein Untertyp einer Klasse überall verwendet werden können soll, wo der Obertyp erlaubt ist. und das ist es da eben probleme gibt, weil der compiler die korrektheit nicht garantieren kann, etc.

was mir oft nicht klar ist, ist, wie man dieses problem am besten umgeht

Prinzipiell hast du recht. Allerdings gibt es nur dann Probleme wenn du generische Klassen mit nicht generischen mischt. Wenn du nur generische Klassen benutzt (im eigene Code sowie nur generische Klassen irgendwelcher Bibliotheken) wirst du keine Probleme bekommen. Wenn du nur generische Klassen einsetzt weiß der Compiler immer welchen Typ die Daten haben.

ich habe eine Klasse TableInfo, die Informationen wie die Größe, das Gewicht, etc. eines Tisches kapselt + ein paar Methoden anbieten, um damit zu arbeiten. Die TableInfo wird von einigen Klassen verwendet. diese brauchen nicht mehr Informationen/Methoden, als TableInfo bietet. passt also so wie es ist.
An einer Steller aber reicht TableInfo nicht aus. Dort ist zb auch die Farbe oder die Holzart des Tisches von Bedeutung. Ich brauche aber weiterhin alle Infos+Methoden, die schon TableInfo bereitstellt. Für mich erscheint es nun logisch, TableInfo zu erweitern: also zb TableMoreInfo extends TableInfo.
bis hierhin gibts kein problem.

Das klinkt so weit schlüssig

nun hat ein Tisch aber noch eine Liste von Dingen, die sich auf ihm befinden (Stifte, Bücher, etc.) und auch über diese Dinge gibt es Information
--> List<ThingInfo>
das große problem ist nun, dass ein TableMoreInfo Objekt auch eine List<ThingMoreInfo> benötigt.

An dieser Stelle verstehe ich nicht warum es eine Klasse "ThingMoreInfo" gibt. Sind die Dinge die auf einem "normalen" Tisch stehen können nicht die gleichen wie die die auf einem erweitertem Tisch? Und wenn es einen Grund gibt können dann nicht dennoch Gegenstände der Klasse "ThingInfo" auf einem "TableMoreInfo" stehen?

ich frage mich nun, wie man sowas am besten löst. auf die vererbung zwischen TableInfo und TableMoreInfo will ich nicht verzichten, da ich den gesamten Code dann rüberkopieren müsste (und bei jeder Änderung an beiden Stellen ändern). eine überlegung war, die ThingMoreInfo objekte in die List<ThingInfo> zu schreiben. und beim Zugriff auf Elemente dieser Liste von TableMoreInfo aus einfach alle Elemente auf ThingMoreInfo zu casten. das problem, dass ich dann überall im code sehr viele casts hätte. was ich dann probiert habe, ist, einfach Methoden anzubieten, die aus der List<ThingInfo> von TableInfo eine List<ThingMoreInfo> erzeugen. (mit casts) und diese dann anbieten. das klappt eigentlich ganz gut und es sind fast alle casts weg. leider hat das aber natürlich den nachteil, dass es sich nicht mehr um die originalliste handelt. bei änderungen am original, ändert sich die kopie nicht.
meine nächste variante wären zwei listen, also die aus TableInfo plus eine weitere in TableMoreInfo und diese dann immer am selben Stand halten. damit hätte ich zwei eigentlich komplett idente liste, nur eben unterschiedlich typisierte list-referenzen. naja, auch nicht schön.

Und hier verstehe ich ehrlich gesagt fast nur noch Bahnhof - sorry! Könntest du bitte dein Problem an dieser Stelle nochmals etwas umformulieren und am besten etwas Code posten?

gibts für sowas ein designpattern bzw. ne patentlösung, wie es am besten gemacht wird?

Bestimmt. Interfaces bieten sich auf jeden Fall schon einmal an... aber darauf gehe ich ein wenn ich dein Problem etwas genauer verstanden habe...

MfG,
Hilefoks

 

[-frank]

An dieser Stelle verstehe ich nicht warum es eine Klasse "ThingMoreInfo" gibt. Sind die Dinge die auf einem "normalen" Tisch stehen können nicht die gleichen wie die die auf einem erweitertem Tisch? Und wenn es einen Grund gibt können dann nicht dennoch Gegenstände der Klasse "ThingInfo" auf einem "TableMoreInfo" stehen?

nein, das kann nicht vorkommen. es sieht so aus, dass ich in einem programmteil immer nur Info Objekte habe. (diese habe ich auch früher geschrieben als es die MoreInfo Objekte noch garnicht gab.)
Nun kommt ein weiterer Programmteil, der aber eben MoreInfo Objekte benötigt. (die Programmteile haben nicht mal viel miteinander zu tun. dort, wo ich MoreInfo Objekte habe, kommen immer nur MoreInfo objekte vor.)

Und hier verstehe ich ehrlich gesagt fast nur noch Bahnhof - sorry! Könntest du bitte dein Problem an dieser Stelle nochmals etwas umformulieren und am besten etwas Code posten?

ich versuchs:

class TableInfo {

    // viele felder mit eigenschaften
    // viele getter/setter, etc.
    ...

    // Liste von Gegenständen
    List<ThingInfo> things;



    //methoden:

    List<ThingInfo> getThings() {..}

    List<ThingInfo> getBigThings() {...}
}

class TableMoreInfo {

    //weitere eigenschaften
    ...


    // methoden:
    Color getTableColor() {..}

    Color getColorOfThing(String nameOfThing) {..}

    void removeYellowBigThings() {..}

    static List<ThingMoreInfo> convertList(List<ThingInfo> list) {..}

    static List<ThingMoreInfo> getYellowThings(List<ThingMoreInfo> list) ..

}

das problem ist, dass zb die methode getThings(), die ich ja auch bei TableMoreInfo objekten verwenden will, eben nur ne List<ThingInfo> zurückgibt. das stört mich, weil ich in dem programmteil wie gesagt nur MoreInfo objekte habe. ich würde die casts gerne vermeiden bzw. aufs nötigste reduzieren.
dafür gäbs dann auch die Methode convertList(..). die soll die ursprüngliche liste returnieren, erzeugt dazu aber ne kopie der list und zwar vom type List<ThingMoreInfo> --> keine casts mehr bis auf in dieser methode.
das nächste problem kommt dann zb bei removeYellowBigThings(). es wäre eventuell angenehm, die methode getBigThings() zu verwenden. auch hier müsste man dann aber wieder convertieren.
ob es designtechnisch eine gute idee ist, bin ich nicht sicher, aber wenn es zb dann noch möglich sein soll, dass die liste von außen verändert wird bzw. dass sie von außen beobachtet werden soll (sprich die referenz auf die liste nach außen weitergeben), dann scheitert die convertList-Variante, denn die hat ja nur ne kopie der liste geliefert.
aber okay, das ist vielleicht eh nicht die beste idee...

naja, mir sind aber jetzt so beim durchüberlegen doch ein paar dinge auf/eingefallen, wie ich es anders/besser lösen könnte. ich denke, das unnatürliche an dem ganzen ist einfach, dass ein XYMoreInfo objekt zwar eine Erweiterung zu XYInfo ist, aber wie gesagt dessen eigene Listen auch immer nur mit ABCMoreInfo-Objekten befüllt werden dürfen. von daher kann man XYMoreInfo nicht überall einsetzen, wo ma XYInfo einsetzen kann.
dass das nicht passiert, kann ich für mein programm zwar garantieren, aber vom design her ist es vielleicht trotzdem etwas seltsam.

naja, ist außerdem schon spät, morgen denke ich hoffentlich klarer

 

[schalentier]

Was du machen koenntest waere:

class TableInfo<T extends ThingInfo>{
   List<T> thingList;
   List<T> getThingList();
}

class TableMoreInfo extends TableInfo<ThingMoreInfo>{
   void foo(){
     getThingList().get(0) // --> liefert ThingMoreInfo Instanz
   }
}

Generell gefaellt mir persoenlich das aber ueberhaupt nicht. Irgendwie hab ich den Eindruck, das macht OOP kaputt, da man quasi immer mit konkreten Objekten arbeitet, und sich keine Gedanken machen muss, wie man einen geschickten Vererbungsbaum konstruiert.

Was haben eigentlich alle gegen Casts? IMHO sind die Kosten, die man bezahlt um auf Casts zu verzichten (Generics) viel zu hoch. Der einzige Vorteil, der mir auf Anhieb auffaellt ist die bessere Unterstuetzung einer IDE beim Einsatz von Generics, da diese immer alle Methoden anbietet, wenn man "." eingibt.

Was spricht hiergegen:

class TableInfo {
   List<ThingInfo> thingList;
   List<ThingInfo> getThingList();
}

class TableMoreInfo extends TableInfo{
   ThingMoreInfo getThingMoreInfo( int index ){
      // todo check range!
      // todo check valid cast!
      return (ThingMoreInfo) getThingList().get( index );
   }
}

Damit gibts genau einen Cast. Wo is das Problem?

 

[-frank]

mit Java5 wurden eben endlich die Generics eingeführt. Plötzlich hat man Typsicherheit bei den Collections und keine Casts mehr. daran habe ich mich halt gewöhnt.
ich geb dir aber recht: jetzt wo ich so drüber nachgedacht habe, würde ich zuviel aufgeben/verkomplizieren, nur um auf die casts zu verzichten. das problem ist halt nur, dass ich sehr viele methoden haben werden, die über die ganze liste iterieren und nicht nur ein getMoreThingInfo(index) machen. deswegen habe ich die Casts dann schon überall.
und eine Methode getMoreThingInfoList() kann zwar quasi den List-Cast erledigen, aber dann hab ich eben ne Kopie der Liste. das ist schlecht für Methoden, die eigentlich etwas entfernen müssen aus der Liste.
Aber: eigentlich ist das in meinem speziellen fall kein problem. außerhalb von Table(More)Info, muss ich zu den Listen nichts hinzufügen bzw. entfernen. damit gibts nur casts innerhalb der klasse (nach außen gibts kopien der liste mitgecasteten elementen). innerhalb von TableMoreInfo kann ich dann von fall zu fall unterscheiden, ob ich ebenfalls mit der bereits gecasteten liste arbeite oder auf der originalliste mit casts. (zum glück gehts in meinem speziellen fall nur um die lesbarkeit/wartung der klasse, nicht aber um performance.)

trotzdem finde ich auch variante 1 interessant. ich hab schon auch in diese richtung überlegt. leider bin ich noch etwas unsicher bei dieser einsatzart von generizität. ich denke aber, dass es mühsam werden könnte, wenn das ganze weiter geschachtelt wird, oder?
also zb eine TableInfo hat auch ne Liste von ContainerInfo. ein Container ist zb ne Schachtel. in ner Schachtel gibts wieder ThingInfos. In ner Schachtel kann auch ne weitere Schachtel sein (das ganze ist eben geschachtelt )
und natürlich alles weiter mit MoreInfo und Info - je nachdem.
würde wohl trotzdem funktionieren, was mir aber überhaupt nicht gefällt:
es kann durchaus sein, dass TableInfo nochmal ne ABCInfo Liste dazubekommt. da müsste man den code ja dann überall verändern, also alle Referenzen von zb TableInfo<ThingInfo> auf TableInfo<ThingInfo, ContainerInfo>! (oder hab ich da jetzt nen denkfehler?)
was ebenfalls hinzukommt, ist, dass die normalen Info-Objekte zu nem anderen Programmteil gehören, der eigentlich von der Veränderung garnicht betroffen sein sollte. (wenn die lösung große vorteile bringt, wäre eine änderung aber okay)

wirklich intuitiv wäre für es für mich als Mensch , einfach irgendwie festlegen zu können, dass Info-Objekte eben Listen von Info-Objketen haben und MoreInfo-Objekte haben Listen von MoreInfo-Objekten. Aber das werde ich dem Compiler wohl nicht mitteilen können.

 

[KSG9|sebastian]

Tja..wo wir wieder beim Thema wären "Früher war alles besser?" oder auch "Wozu brauch ich Generics?" oder vielleicht "Macht Autoboxing mehr kaputt als das es hilft?" u.s.w.

 

[schalentier]

wirklich intuitiv wäre für es für mich als Mensch , einfach irgendwie festlegen zu können, dass Info-Objekte eben Listen von Info-Objketen haben und MoreInfo-Objekte haben Listen von MoreInfo-Objekten. Aber das werde ich dem Compiler wohl nicht mitteilen können.

Genau das machst du doch mit Variante 1. Das Argument, wenn du irgendwas in TableInfo aenderst, du auch alle Referenzen aendern musst, ist natuerlich korrekt, hierbei hilft ein Refaktoringtool (bzw eine gute IDE).

Dennoch bleibt bei mir irgendwie der Nachgeschmack von suboptimalem OO Design.

 

[-frank]

Genau das machst du doch mit Variante 1. Das Argument, wenn du irgendwas in TableInfo aenderst, du auch alle Referenzen aendern musst, ist natuerlich korrekt, hierbei hilft ein Refaktoringtool (bzw eine gute IDE).

naja, aber deswegen funkt es eben nicht wirklich. klar erleichtern einem eclipse&co so einiges, aber wenn die Info klassen in andere programmteile integriert sind, die ich nur zur not verändern kann/soll, dann hilft mir das auch nicht viel.

was mir noch eingefallen ist, ist, dass ich die Listen in eigenen Objekten kapseln könnte. zb eine innere Klasse TableInfoList in TableInfo<E extends TableInfoList>. dann könnte ich TableMoreInfo mit <TableMoreInfoLists> initialisieren und müsste bei änderungen nur mehr die listen objekte ändern.

allerdings wird das sicher keinen platz in nem lehrbuch über objektorientierte programmierung finden

ich habs jetzt mit casts gemacht und denke, dass es so okay ist. danke auf jeden fall für die tipps!