Discussion :

[Luigicube]

Bonjour,

J'ai une petite question sur les mots-clés utilisés pour l'héritage.

J'ai une classe abstraite GenericAbstractClass qui a une méthode compute qui rend un objet GenericObject.

J'ai deux types dérivées : A et B. On a donc respectivement une classe AClass et BClass qui dérivent de GenericAbstractClass et AObject et BObject qui dérivent de GenericObject.

Est-ce que je peux redéfinir compute dans AClass et dans BClass pour qu'elle rende respectivement AObject et BObject ?

Je fais pour l'instant dans GenericAbstractClass :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public abstract GenericObject compute()

j'aimerais avoir un truc du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public abstract new AObject compute()

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public abstract new BObject compute()

[Edit : AClass et BClass sont également abstraites, le but c'est d'avoir des classes A1Class, A2Class, etc... qui sachent qu'on rende un AObject]
[Re-Edit : une solution ça serait de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public override GenericObject compute(){return this.computeA();}
public abstract AObject computeA()

Mais, euh, bof.
]

[Bluedeep]

Ce que tu veux faire n'est pas possible (on ne peut pas redéfinir une méthode en changeant juste son type de retour) en revanche l'utilisation des classes ou méthodes génériques t'apporte ici une solution (c'est fait pour cela d'ailleurs).

[Luigicube]

en revanche l'utilisation des classes ou méthodes génériques t'apporte ici une solution (c'est fait pour cela d'ailleurs)

Donc, quelle est la meilleur méthode (?) pour ensuite implémenter une A1Class qui sache qu'elle doive rendre un AObject et ensuite l'utiliser comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
A1Class A1 = new A1Class()
GenericObject obj = A1.compute()

(obj sera un AObject)

[DonQuiche]

Bonjour.

D'abord, est-ce vraiment nécessaire ? Les consommateurs de ces classes ont-ils vraiment besoin de savoir qu'ils manient un AObject plutôt qu'un GenericObject ? Si oui, c'est obligatoirement parce que AObject ajoute des fonctionnalités en plus de celles de GenericObject. Dans ce cas, ok, l'héritage est une des façons de faire ça (il y en a d'autres, voir le pattern décorateur par exemple).

Dans ce cas, il n'y a qu'une façon directe de faire ça : définir de nouvelles méthodes, distinctes, dans AClass et BClass. Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class AClass : GenericAbstractClass
{
   override GenericObject compute() { return computeA(); }
   AObject computeA() {...}
}

Ou, avec une version générique de GenericAbstractClass :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class AClass : GenericAbstractClass<AObject>
{
   override AObject compute() {...}
}

J'insiste bien, ceci n'est nécessaire que si des classes tierces (ni AClass ni AObject) ont besoin de fonctionnalités (méthodes, champs) qui n'existent pas dans GenericObject, uniquement dans AClass.

[Luigicube]

D'abord, est-ce vraiment nécessaire ? Les consommateurs de ces classes ont-ils vraiment besoin de savoir qu'ils manient un AObject plutôt qu'un GenericObject ? Si oui, c'est obligatoirement parce que AObject ajoute des fonctionnalités en plus de celles de GenericObject. Dans ce cas, ok, l'héritage est une des façons de faire ça (il y en a d'autres, voir le pattern décorateur par exemple).

Dans ce cas, il n'y a qu'une façon directe de faire ça : définir de nouvelles méthodes, distinctes, dans AClass et BClass. Par exemple

OK... J'ai fait ce que tu proposais avec l'héritage, je trouvais ça bof mais tu confirmes qu'on ne peut faire autrement. Je cherchais des techniques moins lourdes, je vais regarder le pattern décorateur (ça en devient artistique ma parole).

Oui, les classes qui vont utiliser le résultat de compute() peuvent avoir besoin de savoir à quoi elles ont affaire, dans ce cas je regarde le type et je caste en conséquence. Mais elles peuvent ne pas avoir besoin non plus et dans ce cas là j'utilise directement les méthodes de GenericObject.

Merci DonQuiche & Bluedeep.

[DonQuiche]

Je t'en prie. Note que j'ai ajouté une version générique. Enfin tu as aussi toutes les façons indirectes : passer par des tiers créateurs (patterns Factory, etc) ou encore inverser le contrôle (créer un constructeur de AObject qui accepte un AClass en argument).