Pourquoi est il impossible de créer une méthode static abstraite ?

Bonjour,

Hein pourquoi ! Pourquoi est il impossible de créer une méthode static abstraite ? De même, pourquoi est ce qu'une interface ne peut avoir de fonction static ?

De plus, est ce qu'il existe un moyen pour "forcer" une classe à implémenter une méthode static ?

Parce que une méthode abstraite a vocation a être surcharger d'une classe fille, alors qu'une méthode static partagé par toutes les instance de la classe ne peux pas être surchargé.

Citation:

---

Envoyé par Djobird

De plus, est ce qu'il existe un moyen pour "forcer" une classe à implémenter une méthode static ?

---

non y a pas moyen, par contre si tu nous explique pourquoi tu as cet étrange besoin et qu'est-ce que tu espère en retirer, on pourrait t'expliquer comment faire ca autrement et proprement.

Merci bien pour ces informations.

Pour la raison, je met au point une interface, et je veux que toutes les classes implémentant cette interface soit des singletons.
Donc je voulais ajouter à mon interface une méthode static getInstance(). Alors ca n'aurait certe pas forcer à avoir un singleton, mais au moins cela aurait fait déjà une partie, la suite de l'implémentation du pattern venant logiquement.

Mais je vais mettre en documentation comme quoi cette classe doit être un singleton avec la méthode getInstance();

Citation:

---

Envoyé par Djobird

Donc je voulais ajouter à mon interface une méthode static getInstance().

---

Ceci ne serait pas suffisant car rien n'empêcherait d'avoir un constructeur public, et donc ton singleton pourrait ne pas en être un.

En revanche, rien n'empêcherait de passer par une classe intérmediaire du type (non thread safe etc. et il est possible de réduire les portées suivant ton type) :

Code:

---

1 2 3 4 5 6 7 8 9 10

class SingletonFactory { private Map<Class, Object> instances = new HashMap()....   public static Object getInstance(Class c) { Object o = instances.get(c); if(o == null) { o = c.newInstance(); instances.put(c, o) } return o; } }

---

Mais je vois pas encore clairement pourquoi tous les sous types doivent être des singletons.

c'est curieux de vouloir obliger, dans une interface, le fait que ce soit un singleton. C'est pas vraiment la place pour ce genre de logique. Déjà, si je me base là dessus:


Interface A
B implémente A
C implémente A
D étends B
-> si j'ai une instance de D, je ne peux plus créer d'instance de B?

Même en mettant de la doc 'ca doit être singleton', tu devra quand meme connaitre B, C et D pour appeler getInstance(), parce que A.getInstance() correspondrait à rien.


Si ce que tu cherche c'est un point d'entrée pour créer des singletons, regarde plutot du coté d'une factory où tu aurait une méthode genre

Code:

---

1 2	public class AFactory { public static A getIntance(String type) //.....

---

et c'est cette méthode qui gérerait la logique singleton.

C'est un peu compliqué, d'ailleurs je me complique peut être la vie, mais bon. En gros ca donnerait ca :
J'ai une liste d'objet, avec un identifiant.
Je parcours cette liste, et je regarde leur identifiant. Selon cet identifiant, je vais appliquer un calcul spécifique.

Je veux crééer une API qui permette ceci, tout en laissant la possibilité de rajouter des calculs et sans avoir à toucher au existant code.

Donc pour cela, dans mon moteur de parcours, je vais récupérer l'identifiant, regarder dans un fichier de config quel calcul utiliser, créer dynamiquement l'objet permettant ce calcul (via le classloader), et appeler avec cet objet la méthode permettant de traiter le calcul.

Je veux que tous ces objets soient des singletons afin d'empêcher la création/suppression d'un top grand nombre d'objet. En effet, je pense qu'environ 1000 traitements de ce genre par seconde devraient être effectués (c'est une appli en temps réel). Et, vu que j'aurais au grand maximum une 20ène de traitement différents, le singleton me paraissait une bonne idée.

Mais le SingletonFactory semble faire ce que je cherche, je vais regarder ca de plus près, merci ^^

Citation:

---

Envoyé par Djobird

J'ai une liste d'objet, avec un identifiant.

---

Déjà, mauvais plan. Il y a les tables d'associations pour ça.


Il suffit juste d'avoir quelque chose du type :

Code:

---

1 2 3 4 5 6 7 8

abstract Provider { abstract public Operator getOperatorById(int id); public Class getClassNameById(int id) { //peut également utiliser un cache .... return clazz; } }

---

Que l'on peut implémenté soit simplement :

Code:

---

1 2 3 4 5 6

class DirectProvider extends Provider { public Operator getOperatorById(int id) { return getClassNameById(id).newInstance(); } }

---

Soit via un Cache :

Code:

---

1 2 3 4 5 6 7 8 9 10

//on peut également utiliser un DirectProvider class CacheProvider extends Provider { Map<Integer, Operator> cache = new HashMap(); public Operator getOperatorById(int id) { Operator o = cache.get(id); if(o==null) { o = getClassNameById(id).newInstance(); cache.put(id, o); } return o; } }

---

A noter que la recherche dans le cache sera peut être plus coûteuse que la création de l'objet :roll:
Si les objets se créaient rapidement, le cache sert pas à grand chose.

Citation:

---

Envoyé par Djobird

(c'est une appli en temps réel).

---

J'ai l'impression que tu utilise le mauvais terme (temps réel), mais je te lance quand meme l'avertissement: java n'est pas un système temps réel (ni les windows de bureau, ni mac os x, ni la plus part des linux d'ailleurs)

Citation:

---

Envoyé par Djobird

Et, vu que j'aurais au grand maximum une 20ène de traitement différents, le singleton me paraissait une bonne idée.

---

De fait, ce que tu cherche c'est une factory qui refait toujours la meme instance, comme mentionné dans mon post

En fait, je considère que c'est une appli temps réel car je récupère toutes mes infos d'un flux envoyé en streaming.
Sinon en effet, la factory semble tout à fait correspondre à ce que je veux faire.

Merci bien pour vos conseils ^^