Yo,
Alors, j'ai un ensemble de classes (B, C, D, etc.) qui vont hériter d'une classe abstraite, A. Toutes ces sous-classes auront un attribut static "label", car ce que je veux c'est que chaque sous-classe ait un label associé à la classe. Dans toutes ces classes, j'aurais les mutateurs getLabel() et setLabel(). J'aurais voulu factoriser ça mais après quelques essais je me demande si c'est possible. Car si je fais ça :

Classe A : http://pastebin.com/Gzfeka94
Classes B et C : http://pastebin.com/Wg6RfUMU ; http://pastebin.com/KiXjMsBM
Lanceur : http://pastebin.com/c3RErpep

Mon affichage résulte en :

test
test
test
test
test
test
meeeeep
meeeeep
meeeeep

et non en

test
btest
ctest
test
btest
ctest
meeeeep
btest
ctest

comme ce à quoi je m'attendais. Mon explication c'est que le getLabel() n'est pas recopié, il est simplement appelé depuis la classe mère et du coup c'est le label de la classe mère qu'on récupère. Au passage j'avais mis les labels en private pour qu'ils ne soient pas hérités (avec usufruit du moins) de la classe mère, je sais pas vraiment si ça a son intérêt...
Par contre, si je recopie mes getters dans les sous-classes j'ai bien le résultat attendu. Est-ce que vous voyez un moyen de faire sans pour autant avoir à recopier mes getters dans chaque sous-classe ? J'avais pensé à deux choses :

1. Ne pas définir l'attribut label dans la classe mère, seulement faire une méthode abstraite getLabel(). Le problème c'est que ça force à recopier le même getter dans toutes les sous-classes...

2. Passer par une classe intermédiaire qui ferait le binding classe/label via une HashMap, a priori ç devrait faire ce que je veux mais je pense pas que ce soit top conceptuellement parlant...

Est-ce qu'une de ces deux solutions vous parait bonne ou en voyez-vous une autre ?

Tu essaies de faire quoi? Pourquoi c'est static?

C'est static car je veux un attribut lié à la classe, pas aux instances, tout simplement. C'est pour l'implémentation d'un protocole réseau en fait, j'ai une classe par paquet reçu (chacune de ces classes hérite d'une classe Response) et cet attribut statique représente le processeur associé à la classe. Donc chaque classe aura forcément un processeur (c'est pour ça que je veux qu'il soit statique et c'est pour ça que je veux factoriser). Pour prendre un exemple concret, si j'ai ma classe Ping, elle ressemblera à ça : http://pastebin.com/BzrbGDBk
Ce qu'il me faudrait en fait c'est un peu l'équivalent du mot-clef self de PHP qui retournerait l'attribut processor de la classe effective, car là si je fais Ping.getProcessor() je récupère un DefaultProcessor au lieu d'un PingProcessor.

PommesCarrotes
Posté via mobile le 19 mai 2013 à 01:05:09
this en gros.

Non, tu ne peux pas utiliser this dans une classe statique.

Personne n'aurait une idée ?

OP, soit ta variable est statique soit ell ne l'ai pas. Ca n'a pas de sens d'avoir une variable statique et de vouloir l'acceder par this.my_static_variable

Yep, je parle pas de this mais bien de self, en PHP les deux existe. self c'est la classe effective dans un contexte statique, par exemple si dans ma super classe le getter contient :

return self::label;

et que j'appelle ce getter depuis la sous-classe, c'est l'attribut label de la sous-classe qui sera retourné (sauf erreur de ma part). Après j'ai bien compris qu'il n'existait pas d'équivalent à ce mot-clé en Java. Vu qu'il faut absolument que j'avance, je vais mettre en œuvre ma deuxième solution pour l'instant, mais je reste ouvert à tout.

Et quelque chose dans ce goût?

Dans ta classe mère :
public Response( Processor handler)

Et dans la fille :
public PingResponse() {
super( new PingProcessor() );
}

Ou encore :

public PingResponse( Processor p) {
super( p );
}

Et ensuite :

class PingResponseFactory() {

return
}

}

arf... tab error.

je voulais dire

class PingResponseFactory() {

private Processor proc;

public PingResponseFactory(Processor p) {
this.proc = p
}

public PingResponse createResponse() {
return new PingResponse( proc );
}
}

Si tu tiens à ce que toutes les requêtes utilisent le même processor.
C'est bien plus élégant que trimballer un membre statique mutable entre parents et fils. Généralement utiliser du statique comme référence globale *non constante* c'est rarement une bonne idée, et c'est la porte ouverte à tout plein de problèmes dans les contextes multi-threadés.