Fonctions static, surcharge et généric

Bonjour, je suis en train de me plonger dans le Java afin de faire un site web à l'aide de servlets, mais je butte sur un problème en rapport avec le langage. Voici donc l'énoncé du problème (simplifié pour que ce soit plus clair) :

soit une classe Plante. Je souhaite dériver de cette classe des classes représentant des plantes et les décrivant. Par exemple une classe Rose et une classe Tuya.
Prenons ensuite une dernière classe Jardinier, donc le but est de mettre des plantes dans le jardin en fonction de leur couleur. Je souhaiterai faire appel au Jardinier de la façon suivante:

Jardinier.ajouterFleur(Rose.class);

ou bien

Jardinier.ajouterFleur(Tuya.class);

La classe Jardinier effectue des opérations dépendantes de la couleur des plantes, et doit donc faire appel à la méthode Rose.getColor ou Tuya.getColor. Je souhaite en fait que ces fonctions soient statiques, car elles renvoient une valeur qui n'est pas dépendante d'une instance mais uniquement spécifique à la classe. La déclaration de la fonction getColor doit donc pour moi se situer dans la classe Plante puis être surchargée par les classe héritant (équivalent à une fonction statique virtuelle en C++) mais le compilateur me gronde...

Dernière précision, la fonction ajouterFleur serait de la forme:

public void <F extends Plante> ajouterFleur(Class<F> classeFleur){
    ...
    ... F.getColor() ...
    ...
}

Hélas je ne trouve pas de solutions à ce problème pourtant simple, et je ne veut pas avoir à créer une instance pour appeler une fonction qui me renverra toujours la même valeur (ce que je peux en fait faire avec un singleton, mais bon...).

Tout conseil est bienvenu ! Merci pour votre aide !

neodelphi

Salut,

là comme ça je ne vois que le mécanisme de réflexion pour faire un invoque de ta méthode static...




------------------------------------
"On n'est pas au resto : ici on ne fait pas dans les plats tout cuits ..."

OoWORAoO

Salut,

Une solution envisageable serait de créer une classe Abstraite du syle AbstractFleur qui contiendrait ta méthode statique, et pour chacune de tes classes héritant de celle-ci, tu surchargerais cette méthode là. Du coup, en paramétre de ta méthode "ajouterFleur", tu aurais Class<? extends AbstractFleur> ...

A tester (je ne peux pas garantir que cela va fonctionner, je n'ai pas d'envrionnement pour tester rapidement là où je suis à cette instant T :(       )

Voili voilà

[#Tout le monde a des idées : la preuve, c'est qu'il y en a de mauvaises]
[#Je ne comprends pas tout, mais je parle de tout : c'est ce qui compte]

Salut,

la solution avec reflect soit en restant en accord avec l'origine de la question (perso je trouve la solution de indiana_jules bien plus objet et beaucoup plus propre) :


import java.awt.Color;
import java.lang.reflect.Method;


public class ReflectStatic {
   
    public static void main(String[] args) {
        ReflectStatic rs = new ReflectStatic();
        try {
            rs.ajouterFleur(Rose.class);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public <F extends Plante> void ajouterFleur(Class<F> classeFleur) throws Exception {
        Method getColor = classeFleur.getMethod("getColor", new Class[] {});
        Color c = (Color)getColor.invoke(null, new Object[] {});
        System.out.println("getColor : " + c);
    }
   
    private static class Plante {
        // super caca puis la couleur vaut pour TOUTES les instances de TOUTES les plante....
        public static Color getColor() {
            return Color.RED;
        }
    }
   
    private static class Rose extends Plante {
       
    }
}


------------------------------------
"On n'est pas au resto : ici on ne fait pas dans les plats tout cuits ..."

OoWORAoO

Rebonjour !

Merci pour vos réponse, c'est sympa de pouvoir discuter de ce problème. Twinuts, j'avait un peu réfléchi à cette solution qui fonctionnerait sans doute, mais je n'aime pas du tout cette philosophie et je considère ça comme du hack ou de la bidouille, il n'y pas vraiment de vérifications faites par le compilo sur le code du programmeur... de plus l'appel de la fonction est assez lourd en terme de performances.

Indiana_jules, la surcharge de fonctions statique fonctionne sur des instances, mais à moitié sur des statics. Je m'explique:

class A {
    static void test(){ écrire 'A' }
}

class B extends A {
    static void test(){ écrire 'B' }
}

Si on fait B.test() on obtiend 'B' comme attendu. Si on passe la classe au travers des génériques, de cette façon:

public static <E extends A> String test(Class<E> c){
    return E.test();
}

en fesant test(B.class) on obtien 'A' et non 'B', comme si la surcharge est ignorée. Je trouve que ça fait un peu "bug" comme résultat mais bon, certains disent que c'est la surchage des static qui ne devrait pas marcher si c'était bien foutu.....

J'ai vu des programmeurs recommandant d'utiliser les singletons pour avoir le comportement normal des surcharges, mais je trouve dommage de ne pas utiliser les statics lorsque cela semble logique étant donné que les instances n'apportent rien.

neodelphi

Salut
si tu utilises une version 1.5 ou plus récente, tu peux peut-être mettre une annotation "override" pour bien préciser à la JVM qu'il s'agt d'une surcharge. Peut-êre que cela marchera mieux.

A++

[#Tout le monde a des idées : la preuve, c'est qu'il y en a de mauvaises]
[#Je ne comprends pas tout, mais je parle de tout : c'est ce qui compte]

Salut,

"de plus l'appel de la fonction est assez lourd en terme de performances."
>> détrompe toi


Pour le reste la surcharge avec du static ne sert absolument à rien.... car elle impact absolument tous les objets (même dérivés).... en bref ce que Indiana_jules (corrige moi si je me trompe indi) veux te faire comprendre c'est qu'ici il ne faudrait pas utiliser le static (en plus non justifié)


"mais je trouve dommage de ne pas utiliser les statics lorsque cela semble logique étant donné que les instances n'apportent rien"
>> Tu ne dois pas avoir saisi la portée de static pour dire ça... en gros ce que tu veux faire (enfin le code que tu présentes depuis le début) reviendrait à avoir une seule et unique couleur pour TOUTES les plantes...


------------------------------------
"On n'est pas au resto : ici on ne fait pas dans les plats tout cuits ..."

OoWORAoO

En fait je souhaitai le static chez les classes héritant, et je pensais l'imposer en proposant la méthode en abstrait. Ainsi en donnant un objet Plante le compilateur saurait que quelque soit la classé héritant, il existe la fonction getColor qui peut être appelée sans créer d'instances.

Je justifie l'utilisation du static en expliquant que quelque soit l'instance de Rose, la fonction getColor renvoie toujours la meme valeur. De même pour Tuya, la fonction renvoie toujours la même valeur. C'est du static appliqué à la classe et non à l'ensemble des classes héritant de Plante.

Pour moi une fonction ne doit pas être statique dès que son résultat dépend de l'instance sur laquelle la fonction est appelée.

"de plus l'appel de la fonction est assez lourd en terme de performances."
">> détrompe toi"

Pourtant il ne s'agit plus d'un simple saut, par exemple une instance de Method est crée et des appels d'autres fonctions sont exécutées. L'appel est donc au moins 3 fois plus lourd je pense.

neodelphi

"Je justifie l'utilisation du static en expliquant que quelque soit l'instance de Rose, la fonction getColor renvoie toujours la meme valeur. De même pour Tuya, la fonction renvoie toujours la même valeur. C'est du static appliqué à la classe et non à l'ensemble des classes héritant de Plante."

une rose peut etre rouge, blanche, jaune ....


pourquoi pas une interface ?

Salut,

Effectivement Twinuts, je trouve que l'utilisation d'un static dans ce cadre là est superflu, d'autant plus sheoragath a raison, une rose peut avoir plusieurs couleurs. Du coup, l'utilisation d'une classe abstraite, d'une interface, ou des deux est fortement conseillé. Après, je me posais la question de savoir si on pouvait faire la même chose sur une méthode statique

Je sais que j'ai vu des API (exemple JXTA) qui te "forçait" à déclarer une méthode statique à la classe, en te levant une exception lors de l'insertion / utilisation (il devait faire de l'introspection sans doute pour la détecter).

Néanmoins, le static, il ne faut l'utiliser, soit pour des constantes, soit pour des méthodes "utilitaires", soit pour le singleton. Pour tout le reste, je trouve que ca ne peut apporter que du code spaghetti et assez hideux. Du coup, une bonne approche Objet est conseillé.

Voili voilà

[#Tout le monde a des idées : la preuve, c'est qu'il y en a de mauvaises]
[#Je ne comprends pas tout, mais je parle de tout : c'est ce qui compte]