Abstract / Static : pb conception.

Bonjour,
j'ai un soucis au niveau plutôt conceptuel et je n'arrive pas à m'en dépatouiller ou trouver une solution élégante.

Donc je schématise :
j'ai une classe abstraite A
Celle ci a une méthode static getMessage()

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public abstract class A {   protected static url;   public static String getMessage(String key) { getBundle(url).getString(key); }   // c'est un code exemple, donc je ne décris pas la méthode getBundle }

---

Ensuite j'ai plusieurs classes B, C, D qui héritent de A.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class B extends A { private static final String BUNDLE_NAME = "eg";   static{ url = BUNDLE_NAME; }   private B() { }   }

---

Dans ma méthode getMessage() j'ai besoin d'une variable (url) propre à chaque classes filles (B,C,D) mais là ça ne fonctionne évidemment pas.

Soucis : évidemment on ne peut définir de propriété abstract et static à la fois, ça n'a aucun sens. Mais comment faire pour ça que ça fonctionne?

J'ai tenté de regarder du coté du design pattern singleton mais je ne vois pas non plus comment m'en sortir, idem avec interface, ...
Mais peut être un pattern que je ne vois pas ou une solution toute simple auquel je ne pense pas! (un genre de mot clé "static::" à la PHP 5.3?)

Merci.

Tu te pose peut etre pas la bonne question, pourquoi as tu declarer getMessage() en statique?

Je me suis demandé aussi si le besoin était pas inadapté.
Mais en gros ce sont des classes pour récupérer un message dans des fichiers de properties.

Donc faire une instance n'aurait pas de sens et alourdirait le code pour pas grand chose.

Là le but c'est faire dans chaque projet différent un B.getMessage("monId"). Et bien sûr éviter de redéfinir le corps de la classe A dans toutes mes classes.

A propos on peu avoir le type de url?
et une declaration "simplifiée" de getBundle()?
:mrgreen:

Attend en gros ce que tu veux faire c'est une variable pour A, B, C... et que dans chaque classe fille tu est une valeur differente... c'est pas possible en statique (si je me tompe pas) car si tu modifie url dans B tu va la modifier aussi dans A et par consequence dans C car c'est une fille de A et url est un propriete de A pas de B ou C

Humm url et getBundle n'ont pas d'importance au niveau conceptuel. C'est du code qui fonctionne et le soucis vient de la variable et pas du code.

Et oui je sais bien qu'une variable statique est propre à la classe en elle même et pas à l'instance (mais de toute façon je ne travaille pas ici en instance). C'est bien là mon soucis et ce que j'essaye de "contourner".

D'où un test pour voir si un design pattern singleton (avec possibilité d'une interface à coté) pouvait me sortir de là mais (sauf erreur de ma part) ce n'est pas le cas.

Salut,

Citation:

---

Envoyé par Bacteries

C'est bien là mon soucis et ce que j'essaye de "contourner".

---

Ton soucis c'est que tu essayes de faire de l'héritage avec des éléments static :?



:arrow: Il serait préférable de tout remettre à plat : que veux-tu faire exactement ?


a++

J'ai une classe qui permet de récupérer des messages d'un fichier de properties, en donnant une clé et / ou des valeurs pour certains paramètres.

Je dois utiliser ce comportement dans plusieurs projet différent. J'ai donc mis dans un projet "utils" une classe avec ces méthodes. (dans mon exemple : A)

Je souhaite ensuite avoir une classe par projet (B,C,D) pour récupérer ses messages héritant de cette première classe.

La seule donnée dont j'ai besoin c'est l'emplacement du fichier de message. C'est ce que je met dans mes classes B,C,D.
Et ensuite dans mon code je ne veux pas instancier une classe pour ensuite récupérer mes messages. Là je fais un C.getMessage("macle"); et j'ai le texte correspondant.

Bin je penserai que metre ton url en parametre a ta methode getMessage serai plus simple.

J'appelle cette méthode peut être 100 fois dans chaque projet, donc ça me paraît pas très propre.

Citation:

---

Envoyé par Bacteries

J'appelle cette méthode peut être 100 fois dans chaque projet, donc ça me paraît pas très propre.

---

Alors il faudrait peut-être éviter de faire le getBundle() à chaque getMessage() non ?


Enfin perso je ne vois pas l'intérêt de toutes ces sous-classes B, C, D, etc...

Un seule classe suffit amplement :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public class Messages { private final ResourceBundle bundle;   public Messages(String bundleName) { this.bundle = ResourceBundle.getBundle(bundleName); }   public String getMessage(String key) { return bundle.getString(key); } }

---

Ensuite, libre à ton d'utiliser autant d'instance que nécessaire, éventuellement en static :

Code:

---

1 2 3 4 5

public class MonProjet { public static final Messages A = new Messages("a"); public static final Messages B = new Messages("b"); public static final Messages C = new Messages("c"); }

---

a++

Citation:

---

Envoyé par adiGuba

Salut,
Ton soucis c'est que tu essayes de faire de l'héritage avec des éléments static :?

---

Plus limpide comme explication y a pas :ccool:

Sinon pour ton problème, je vois pas d'autre solution de d'enlever les statiques sur les url et ce qui en decoule (fonction, etc...)
Tu sera obligé de d'instancier B, C ou D.
Donc je ferai quelque chose de moins sophistiqué (y a surement autre chose)

Déclaration de A:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

package test; public class A { protected URL url; //c'est bien ca le type? public A(URL url){ this.url=url; }   public String getMessage(String key) { return getBundle(url).getString(key); } }

---

Declaration de B

Code:

---

1 2 3 4 5 6 7 8 9 10

import test.A;   public class B extends A{   public B(URL url){ super(url); } //++ autres code }

---

Après dans le code tu peu faire:

Code:

---

1 2 3 4

String blague1=null; B toto=new B("toto.txt");//Ok c'est pas forcement une URL valide :P blague1=toto.getMessage("blague1");

---

Si y a d'autres solutions, je suis preneur, je serai moins bête ce soir! :mrgreen:

Je pense que j'ai du mal à me faire comprendre...
(pour GetBundle : j'ai simplifié le code et pas mis tout le code, mais il y a, en gros, tout un mécanisme de cache)

Et dans ton code je pense que tu voulais plutôt faire ça :

Code:

---

new B().getMessage("id");

---

non?

Et de mettre la classe Messages en abstraitre, dont hériterais les classes B et C.

C'est une solution, mais je ne la trouve pas super propre (l'instanciation à chaque fois, donc des objets à chaque fois différent, ...).

Torg666> Oui voilà tu as cerné le problème.
Mais faire des instance à chaque fois me gêne. Comme je le dis c'est appelé une centaine de fois et ici le static a donc tout son intérêt. Et ça allourdit le code (car mon appel à getMessage() peut être utilisé dans x méthode et x classes différentes).

Citation:

---

Envoyé par Bacteries

Et de mettre la classe Messages en abstraitre, dont hériterais les classes B et C.

---

Non tu n'as pas besoin d'héritage ici... c'est un simple attribut qui change. Une classe et plusieurs instances suffisse amplement !

Citation:

---

Envoyé par Bacteries

C'est une solution, mais je ne la trouve pas super propre (l'instanciation à chaque fois, donc des objets à chaque fois différent, ...).

---

Tu parles de quelles solutions ici ?

a++

Citation:

---

Envoyé par Bacteries

Je pense que j'ai du mal à me faire comprendre...
(pour GetBundle : j'ai simplifié le code et pas mis tout le code, mais il y a, en gros, tout un mécanisme de cache)

Et dans ton code je pense que tu voulais plutôt faire ça :

Code:

---

new B().getMessage("id");

---

non?

Et de mettre la classe Messages en abstraitre, dont hériterais les classes B et C.

C'est une solution, mais je ne la trouve pas super propre (l'instanciation à chaque fois, donc des objets à chaque fois différent, ...).

---

Si tu fais ça, c'est le NullPointerException assuré.
Tu n'est pas obliger d'instancier 50 objets, 1 seul suffit. A toi après de pas le donner a manger au GC si tu en as encore besoin.

De plus si tu fait rien de plus dans B, A suffit largement.
Si tu as 50 fichier properties... ben t aura 50 instances de A toute differentes.

l'usage du statique (pour les variables et fonction) n'as d'interet que si ca affecter toutes tes instance d'un classe, par exemple modifier un parametre static sur toute tes instances. (arf je seche sur un exemple... :calim2:)

adiGuba> Je parlais de ta solution.
Dans ton exemple je ne vois pas comment aller cherche mes "messages" dans tes endroits différents.

Ca m'impose de faire un new Message("monChemin").get("monId") à chaque fois que je souhaite l'utiliser (et j'aimerais éviter de créer des instances, pour des soucis de perf notamment).

Citation:

---

Envoyé par Torg666

Si tu fais ça, c'est le NullPointerException assuré.
Tu n'est pas obliger d'instancier 50 objets, 1 seul suffit. A toi après de pas le donner a manger au GC si tu en as encore besoin.

De plus si tu fait rien de plus dans B, A suffit largement.
Si tu as 50 fichier properties... ben t aura 50 instances de A toute differentes.

l'usage du statique (pour les variables et fonction) n'as d'interet que si ca affecter toutes tes instance d'un classe, par exemple modifier un parametre static sur toute tes instances. (arf je seche sur un exemple... :calim2:)

---

Oui mais comme mon actuel Message.getMessage() est utilisé dans plein de classe / méthode je dois soit trimballer mon objet soit l'instancier à nouveau plein de fois.
Et j'ai un fichier properties par "classe" (B, C, D), voilà pourquoi je cherche à ne mettre ce path que dans B, C et D et ensuite utiliser un traitement commun dans A.
Et surtout éviter une lecture à chaque fois de ce fichier de properties à chaque appel de ma méthode.

Citation:

---

Envoyé par Bacteries

Oui mais comme mon actuel Message.getMessage() est utilisé dans plein de classe / méthode je dois soit trimballer mon objet soit l'instancier à nouveau plein de fois.
Et j'ai un fichier properties par "classe" (B, C, D), voilà pourquoi je cherche à ne mettre ce path que dans B, C et D et ensuite utiliser un traitement commun dans A.
Et surtout éviter une lecture à chaque fois de ce fichier de properties à chaque appel de ma méthode.

---

La seule autre solution, et qui dépasse largement l'hérésie seulon moi, c'est:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public class A{ private static file String url1="toto.txt"; private static file String url2="dupond.txt"; //etc... pour tout tes fichier properties   static String getTotoBlague1(){ return getMessage(url1,"blague1"); }   static String getTotoBlague2(){ return getMessage(url1,"blague2"); }   static String getDupondBlague1(){ return getMessage(url2,"blague1"); }   static String getDupondBlague2(){ return getMessage(url2,"blague2"); } //etc.. et ca pour tout tes fichiers et tes proprietes...:aie: static String getMessage(String url, string propriete){ return getbundle(url).getMessage(propriete); } }

---

mais bon si tu fais ca.... tu finira cuit a petit feu dans une immense tasse a café! :cfou:

Ah ah, oui en effet.
Et ça ne répond pas à mon soucis de vouloir avoir juste un attribut dans une classe et le traitement dans la classe au dessus (tout en static évidement pour plus de fun).

Citation:

---

Envoyé par Bacteries

adiGuba> Je parlais de ta solution.
Dans ton exemple je ne vois pas comment aller cherche mes "messages" dans tes endroits différents.

---

Code:

---

1 2 3

MonProjet.A.getMessage("clef"); MonProjet.B.getMessage("clef"); MonProjet.C.getMessage("clef");

---

a++

En plus, tu va devoir charger tes fichiers propriete en memoire donc si t en as 50 t'aura 50 fichiers en memoire (et donc a priori créer des objets).

Donc au final, le seul avantage c'est de pouvoir y acceder de n'importe où, et les perfs seront equivalente.

Perso moi je prefere me taper des references entre mes objets, plutot que de faire ca! Je vais commencer à faire chauffer le café! :fessee:

+1 pour la solution d'Adiguba, un pattern state des plus classiques.

un constructeur privé et des instances statiques pour chacun de tes bundles

Note à moi même: un livre sur les design pattern s'impose! :mrgreen:

adiGuba> Merci, oui en effet en relisant ça me semble évident. J'étais peut être trop partie dans ma vision PHP 5.3 de la chose.

Torg666> Toujours utile, et évite de réinventer la roue ;)