[Java] Object inheritance en return types

[Keiichi]

In java heb ik class met de naam 'CommonObject'. Deze wordt door een heel aantal andere classes geerfd.

In die 'child'classes wil ik een functie die overal gelijk is, die een return type van zichzelf hebben. Class_1.function() moet een Class_1 returned, Class_2.function() moet een Class_2 returnen. Function() doet alleen iets met attributen in 'CommonObject' gedefineerd.

Het leek me logisch om deze functie dan ook in 'CommonObject' onder te brengen en hierbij het returntype 'CommonObject' te returnen.

Dit heb ik gedaan, en Class_1.function() gecalled en gecast. Hierop kreeg ik een ClassCastExption.

Mag en kan het wel wat ik wil?

[Verwijderd]

( na snelle scout over je posts )
Zijn generics niet wat je zoekt?

http://www.deitel.com/art...uctionToJavaGenerics.html

[Remus]

Ik weet niet precies wat je wilt bereiken, maar een term als 'CommonObject' komt mij nogal voor als een slechte oplossing. In OO is inheritance over het algemeen niet de oplossing voor de meeste problemen. Ik zou in ieder geval nog eens goed nadenken over je ontwerp.

[Woy]

Ik snap ook niet helemaal wat je wilt, maar hetvolgende gaat toch gewoon goed

Java:

public abstract class CommonObject
{
    public abstract CommonObject Function();
}
public class NotSoCommonObject extends CommonObject
{
    public CommonObject Function(){
        return NotSoCommonObject();
    }
}

NotSoCommonObject obj = new NotSoCommonObject();

obj = (NotSoCommonObject)obj.Function();

Maar waarom moet je later nog casten naar de sub-class van CommonObject. Je zegt dat je alleen dingen uit de CommonObject class gebruikt, waarom gebruik je dan ook niet overal dat type?

[ Voor 19% gewijzigd door Woy op 28-04-2009 16:57 ]

[Janoz]

Keiichi schreef op dinsdag 28 april 2009 @ 16:25:
Dit heb ik gedaan, en Class_1.function() gecalled en gecast. Hierop kreeg ik een ClassCastExption.

Heb je ook een stukje code hiervan? Ik kan me namelijk nogal slecht een voorstelling maken van het beschreven probleem. In java is het bij het overerven van een methode gewoon mogelijk om een 'narrower' returntype op te geven. De volgende code werkt gewoon:

Java:

public class Super {

    public Super function(){
        //doStuff
        return null;// return iets van super
    }
}

public class Child extends Super{

    @Override
    public Child function() {
        //do stuff
        return null; // return iets van child
    }
}

[Nick_S]

En anders met generics:

Java:

public abstract class CommonObject<E extends CommonObject>
{
    public abstract <E> function();
}
public class NotSoCommonObject extends CommonObject<NotSoCommonObject>
{
    public CommonObject Function(){
        return NotSoCommonObject();
    }
}

NotSoCommonObject obj = new NotSoCommonObject();

obj = obj.Function();

[Janoz]

Je code is niet helemaal correct. In het NotSoCommonObject is de naam van de function fout en het returntype niet juist.

[Keiichi]

Met generics kom ik er niet uit.

Dit is een voorbeeld code hoe het nu in elkaar zit:

Java:

class CommonObject {
    CommonObject() { }
    
    public CommonObject function() {
        CommonObject tmp = new CommonObject();
        // Do something with tmp
        return tmp;
    }
    public String AnotherFunction() {
        return "Something specific done to CommonObject attributes";
    }
}

class Child_1 extends CommonObject{
    Child_1() {
        super();
    }
}


class CommonTest {
  public static void main(String args[]) {
    Child_1 c1 = new Child_1();
    Child_1 another_instance = (Child_1)c1.function();
    System.out.println("Hello! " + another_instance.AnotherFunction());
  }
}

Dit is een testcase op basis van waarmee ik bezig ben, maar dit zou wel het idee moeten schetsen. Het idee lijkt ontzettend onlogisch, maar het waarom is terug te vinden in de grote code, schiet me daar dus niet op af

in function() gebeuren dus alleen dingen die betrekking hebben op attributen gedefineerd in 'CommonObject' en op basis daarvan moet dan een nieuwe Child_1 object worden gegeven. Er is natuurlijk altijd die optie op in alle child classes (Het zijn er in het echt iets van 10 stuks) function() te schrijven, maar vanwege eerder genoemd feit is het er niet de plaats voor lijkt me.

[Janoz]

Het probleem is dat je een CommonObject aanmaakt. Dat kan natuurlijk nooit een Child_1 worden. Inheritance werkt de andere kant op. Je maakt een Child_1 aan en die kan zich voordoen als een CommonObject, maar zal altijd een Child_1 blijven.

Ik blijf dus wel erg benieuwd naar 'de grote code' want ik ben erg benieuwd naar het waarom. Ik vermoed namelijk dat er een verkeerde oplossingsrichting gekozen is. Het komt op mij heel vreemd over dat een instantie van een object een instantie van dat object kan maken. Het lijkt nu een beetje alsof een object de factory van zichzelf is. De enige usecase die ik daar zo snel voor kan verzinnen is een clone(), maar dat zit al standaard in java.

Een oplossing zou trouwens kunnen zijn om het volgende te doen:

Java:

public class Super {

    public Super constructAnotherInstance() {
        return new Super();
    }

    public Super function(){
        Super result = constructAnotherInstance();
        //dostuff
        return result;
    }
}

public class Child extends Super{

    public Child constructAnotherInstance() {
        return new Child();
    }

    @Override
    public Child function() {
        Child result = (Child)super.function();
        //do stuff
        return result;
    }
}

[Nick_S]

Janoz schreef op woensdag 29 april 2009 @ 09:22:
Je code is niet helemaal correct. In het NotSoCommonObject is de naam van de function fout en het returntype niet juist.

Volgende keer zal ik m'n code weer even langs een compiler of IDE halen, dat was ik dit keer even vergeten. De eerste keer dat ik Function zag staan heb ik hem inderdaad veranderd naar eentje zonder hoofdletter. (Wie schrijft er nou methodes met een hoofdletter. En het returntype was het verkeerde knippen/plakken.

[.oisyn]

Nick_S schreef op woensdag 29 april 2009 @ 17:46:
Wie schrijft er nou methodes met een hoofdletter.

.Net programmeurs