Klasse soll sich selbst returnieren mit entsprechendem Typ.

[-frank]

angenommen ich habe sehr viele klassen, die alle die Klasse A extenden und alle eine Methode bieten sollen, die das Objekt selbst zurückgibt (warum auch immer...), wobei der return-type der entsprechende untertyp sein soll, also nicht A, sondern zb ExtendedA. ist es mit generics (oder sonst wie) möglich, diese methode in der abstrakten klasse A zu implementieren und nicht in unzähligen subklassen?

mein ansatz wäre gewesen:

public abstract class A<T extends A<T>> {
    T getA() {
        return this;
    }
}

dies funktioniert nicht. ich kann die methode abstrakt machen und somit erzwingen, dass sie jede subklasse implementiert, aber so wie oben bekomme ich einen "cannot convert from A<T> to T" error. (wobei ich schon verstehe, warum es nicht geht, aber nicht wie es stattdessen ginge bzw. ob überhaupt)

 

[SlaterB]

weil this nunmal A ist und nicht T?!

public abstract class A<T extends A<T>>
{
    A<T> getA()
    {
        return this;
    }
}

edit: ok, ich sehe worauf du hinauswillst, kann dir dazu aber keine Lösung nennen

edit:
oder doch?

public abstract class A<T extends A<T>>
{
    T getA()
    {
        return (T) this;
    }
    public static void main(String[] args)
    {
        B b = new B();
        
        B c = b.getA();
    }
}


class B extends A[B] {
    
}

 

[-frank]

weil this nunmal A ist und nicht T?!

ja, mir ist schon klar, dass es so nicht gehen kann, weil T ein anderes A sein kann als A. was ich erreichen wollte, ist folgendes:

klasse A1 hat eine Methode

public A1 getA() {
    return this;
}

klasse A2 hat eine Methode

public A2 getA() {
    return this;
}

..

usw.
ich wollte, dass A1 A erweitert und den eigenen Typ übergibt, also A1 extends A<A1> und dafür soll die getA() Methode gleich in A implementiert werden. kann ich das so bzw. so ähnlich erreichen?

edit: (erst jetzt das zweite posting gelesen)
durch all die versuce mit generics hab ich schon ganz die guten alten casts vergessen
--> mit diesem einen (unsicheren) cast gehts also, danke! ohne cast bzw. ohne unsicheren cast gehts aber nicht, oder?

 

[Guest]

interface IA<T extends IA<T>>
{
   IA<T> getA();   
}

abstract class A<T extends A<T>> implements IA<T>
{ 
   public IA<T> getA()
   {
      return this;
   }
}

class B extends A[B]
{
}

:roll: :bahnhof:

 

[SlaterB]

ohne cast bzw. ohne unsicheren cast gehts aber nicht, oder?

Ansprüche sind das.., bin froh, überhaupt den Cast gefunden zu haben

 

[Kim Stebel]

angenommen ich habe sehr viele klassen, die alle die Klasse A extenden

@ SlaterB:
Das ist bei deinem Vorschlag nicht der Fall. B extends A, C extends A<C> etc...aber es gibt keine Klasse, von der sowohl B als auch C erben. Insbesondere erben sie nicht von A<Object>. Oder hat frank seine Frage falsch formuliert und du hast sie zufällig so falsch verstanden, wie er sie ursprünglich meinte?

 

[SlaterB]

häh, von B und C erben? ne, da verstehe mindestens ich dich nicht,
wer wen falsch, das weiß ich nicht

 

[Kim Stebel]

häh, von B und C erben?

umgekehrt! es gibt keine Klasse, _von der_ B und C erben, was frank ja wollte.(zumindest so wie er das formuliert hat.) A sollte ja die Klasse sein von der die vielen anderen Klassen B, C.....Z erben.

 

[SlaterB]

also B in meinem Beispiel erbt offensichtlich von A, warum nicht auch eine andere Klasse C?

 

[Kim Stebel]

also B in meinem Beispiel erbt offensichtlich von A

B erbt von A, nicht von A.
Und C würde dann von A<C> erben und nicht von A.

 

[SlaterB]

so meinst du das,
na ist ja nicht weiter schlimm,
wenn A irgendwelche gemeinsame Funktionalität enthält, könnte man die ja noch in einer Oberklasse von A zugägnlich machen,
und A selber kann man ohne generischen Parameter eh nicht nutzen

 

[-frank]

ohne cast bzw. ohne unsicheren cast gehts aber nicht, oder?

Ansprüche sind das.., bin froh, überhaupt den Cast gefunden zu haben

*gg*
ist jetzt mehr schon ne frage rein aus interesse. mir tut der cast an der einen stelle absolut nicht weh, aber mich hätts eben interessiert, obs ohne geht.

@gast:
ich bin jetzt selbst schon etwas verwirrt, aber in deinem beispiel bekomme ich doch ein IA<T>.

B b = .. // irgend ein B
B obj1 = b.getA(); // geht nicht (ohne cast)
IA[B] obj2 = b.getA(); // geht.

das heißt, ich erreiche so nicht (ganz), was ich wollte. oder seh ich das falsch?

 

[Guest]

...
@gast:
ich bin jetzt selbst schon etwas verwirrt, aber in deinem beispiel bekomme ich doch ein IA<T>.

B b = .. // irgend ein B
B obj1 = b.getA(); // geht nicht (ohne cast)
IA[B] obj2 = b.getA(); // geht.

das heißt, ich erreiche so nicht (ganz), was ich wollte. oder seh ich das falsch?

Ähmmm ja.

Noch eine Variante

interface IA<T extends IA<?>> 
{ 
   T getA();    
} 

abstract class A<T extends IA<?>> implements IA<A<T>> 
{ 
   public A<T> getA() 
   { 
      return this; 
   } 
} 

class B<T extends IA<?>> extends A<B<T>> 
{ 
   public B<T> getA() 
   { 
      return this; 
   } 
}


B<IA<?>> b = new B<IA<?>>();
B<IA<?>> c = b.getA();

Wenn du sowas machen musst, dann würde ich das Design überdenken.

 

[-frank]

öhm, ja, eh... also auf den ersten blick blick ich da nicht mehr durch. werds mir morgen nochmal ansehen
... was und zu dieser aussage führt:

Wenn du sowas machen musst, dann würde ich das Design überdenken.

... womit du wohl recht hast! so wärs auf jeden fall schon zu kompliziert.

was ich erreichen wollte:
angenommen ich habe ein interface Paintable. alle klassen, die paintable sind, implementieren die Methode getPaintData(). da es aber verschiedene PaintDatas gibt (zb DogPaintData, CatPaintData, etc.) bekommt Paintable den generischen parameter <T extends PaintData>. somit bietet jedes Paintable-Object die getPaintable()-Methode mit dem richtigen Returnparameter an. soweit so gut. was ich nun noch wollte, ist, dass PaintData-Objekte selbst auch Paintable implementieren (was ja in diesem fall IMO durchaus sinn machen würde). sie müssten nur sich selbst returnieren.
so bin ich auf das problem gestoßen. wobei es mich jetzt auch einfach interessiert, ob und wie man es lösen könnte (egal wie kompliziert). im endeffekt werde ich aber wohl kein generic-monster konstruieren, wenns dadurch zu komplizert wird. aber ich habe auch das gefühl, dass ich bei solchen spielerein durchaus auch was lerne, von daher mag ich solche spielereien. gerade weil ich generics lange zeit aus dem weg gegangen bin.

 

[Guest]

Das wäre dann sowas dieser Art.

interface Paintable<TPaintData extends PaintData>
{
   TPaintData getPaintData();
}

interface PaintData extends Paintable<PaintData>
{
   void foo();
}

abstract class AbstractPaintable<TPaintData extends PaintData> implements Paintable<TPaintData>
{
}

class DogPaintable extends AbstractPaintable<DogPaintData>
{
   public DogPaintData getPaintData()
   {
      return ...;
   }
}

class DogPaintData implements PaintData
{
   public DogPaintData getPaintData()
   {
      return this;
   }

// oder auch
//   public PaintData getPaintData()
//   {
//      return this;
//   }
   
   public void foo()
   {
   }
}

 

[-frank]

Das wäre dann sowas dieser Art

jein. ich wollte die Methode eben in AbstractPaintable bzw. PaintData haben und nicht in DogPaintable bzw. DogPaintData. durch die übergabe des typs mittels generics funkt das für AbstractPaintable auch wunderbar, bei PaintData ist aber eben ein cast nötig (was ja nicht so schlimm) oder aber eben so wie in deinem beispiel, dass alle subklassen die methode selbst implementieren. in letzterem fall gibts halt viel code redundanzen (besonders wenn man sich vorstellt, dass es noch ein paar mehr solche methoden gibt, wo die klasse ihre typ kennen sollte)