Pattern Factory avec de la refléxivité

Bonjour,

J'ai un peu de mal à réaliser correctement un pattern factory.

Au début je faisais un switch d'une chaine de caractère pour instancier la classe que je voulais.
Mais finalement je me suis dit que je faisais des choses pour rien. Donc j'ai remplacer mon switch par de la réflexion.

Du coup ma factory ressemble à ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public IAction createAction(Class c) { IAction action = null; try { action = (IAction) c.newInstance(); } catch (InstantiationException | IllegalAccessException ex) { Logger.getLogger(ActionBackOfficeFactory.class .getName()).log(Level.SEVERE, null, ex); } finally { return action; } }

---

Cependant est-ce vraiment une bonne chose ?
A quoi devrai ressembler ma factory ?

Hello,

Quel est le but visé avec ce pattern ? Est-ce que c'est censé être une Factory Method ? Une Abstract Factory ?

Il y a vraiment moyen de se tirer une balle dans le pied avec ce genre de patterns si on ne sait pas exactement où on va. Le

Code:

---

(IAction) c.newInstance()

---

me parait d'ailleurs douteux.

Pour ma part, si on parle vraiment d'une Abstract Factory, je ne l'utilise que dans des cas exceptionnels quand l'objet O1 a besoin de contrôler de A à Z le cycle de vie d'un autre objet O2 dont il dépend. A ce moment là, on ne peut pas passer O2 par injection de dépendance, on est obligé de passer une Factory. Dans tous les autres cas, j'utilise l'injection de dépendance directe qui est mille fois plus simple et plus adaptée à la plupart des situations.

Le but visé était :
j'ai plusieurs classe qui on la même façon de fonctionner. Toute hérite de mon interface IAction.
Au lieu de faire toujours des new dans mon code, je veux juste appeler une fonction et lui passer la class qui m’intéresse.
Je ne sais pas ce qu'est une factory méthode, j'ai voulu faire tous simplement une factory classique.

Avant dans mon code je devais faire

Code:

---

IAction action = new MyAction();

---

Maintenant je fais ne fait plus de new partout dans mon code je fais :

Code:

---

IActionaction = ActionBackOfficeFactory.getInstance().createAction(MyAction.class);

---

Pour moi l'erreur c'est d'utiliser systématiquement une Factory dès qu'on a des classes "qui ont la même façon de fonctionner" en croyant que ça va agir de manière magique...

Petit rappel des faits :

Quand on a des classes similaires, l'idée est de rendre le code qui dépend de ces classes (= leurs consommateurs) ignorants des particularités de ces classes. En d'autres termes, on rend abstraits tout une gamme objets aux yeux de leurs consommateurs pour que les consommateurs les traitent exactement de la même manière et ne voient pas la différence. L'abstraction se traduit en général en orienté objet par des classes abstraites ou des interfaces (le fameux IAction).

Mais il y a une autre étape à réaliser si on veut que le code client soit complètement ignorant de la classe concrète qui est utilisée : ce n'est pas lui qui doit l'instancier, puisque instancier implique de connaître la classe concrète ! L'objet client C doit donc

• soit demander à un objet tiers d'instancier sa dépendance D, tout en restant maître du moment où on instancie D. C'est ce qui se passe dans le cas de la Factory puisqu'on demande à la Factory de créer un objet quand on veut.

• soit déléguer entièrement à un autre objet le choix du moment et les détails d'instanciation de D, être donc d'être totalement passif en se contentant de recevoir D tout prêt dans son constructeur. C'est ce qui se passe dans le cas d'une injection de dépendance "normale" où le contexte (en général un conteneur IoC) s'occupe d'instancier les dépendances et de les injecter dans leurs consommateurs.

Ceci posé, pour revenir à l'exemple qui nous intéresse, le code IActionaction = ActionBackOfficeFactory.getInstance().createAction(MyAction.class) ne nous est d'aucun secours par rapport à IAction action = new MyAction() puisque dans les deux cas on doit connaitre la classe concrète à implémenter (MyAction), on ne bénéficie donc pas d'une quelconque abstraction à ce niveau du code !

Merci du rappel des fait l'erreur est plus clair expliqué comme ça.

Ce dont j'essaye de me rapprocher c'est de ce cas là :

Citation:

---

soit demander à un objet tiers d'instancier sa dépendance D, tout en restant maître du moment où on instancie D. C'est ce qui se passe dans le cas de la Factory.

---

Mais ne fait j'ai pas l'impression que ça convienne dans mon cas. Ca reviendrait à faire une factory par classe et ce n'est clairement pas ce que je voulais faire?

Quel est le type de décision qui détermine l'implémentation concrète de IAction à utiliser ?

- Il y a telle valeur dans le fichier de config donc on va tout le temps instancier un MyAction partout dans l'application ?

- Pour cet objet métier, il y a telle valeur dans la base de donnée donc on va instancier un MyAction plutôt qu'un FooAction ?

- L'utilisateur est sur la page Machin donc on instancie un MachinAction ?

- etc...

le contexte fait tout, sans le connaitre on ne peut pas répondre de manière précise...

Citation:

---

Envoyé par Luckyluke34

Quel est le type de décision qui détermine l'implémentation concrète de IAction à utiliser ?

- Il y a telle valeur dans le fichier de config donc on va tout le temps instancier un MyAction partout dans l'application ?

- Pour cet objet métier, il y a telle valeur dans la base de donnée donc on va instancier un MyAction plutôt qu'un FooAction ?

- L'utilisateur est sur la page Machin donc on instancie un MachinAction ?

- etc...

le contexte fait tout, sans le connaitre on ne peut pas répondre de manière précise...

---

C'est un événement créer par l’utilisateur qui provoque l'implémentation concrète de IAction.
Précisément c'est un clique sur un bouton qui va appeler une certaine fonction. Dans cette fonction un ou plusieurs type d'action peuvent être utilisé.

En code ça donne cela

Code:

---

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

public void actionPerformed(ActionEvent e) { String actionName = e.getActionCommand() + "Action"; try { Method actionToPerform = Dispatcher.class.getDeclaredMethod(actionName); actionToPerform.invoke(this); } catch (InvocationTargetException | IllegalArgumentException | IllegalAccessException | NoSuchMethodException | SecurityException ex) { Logger.getLogger(Dispatcher.class.getName()).log(Level.SEVERE, "Unknown action: " + actionName, ex); } }   public void logAccountAction() { System.err.println("log"); IAction action = new MyAction(); boolean connect = action.execute(); }   public void otherAction() { System.err.println("log"); IAction action = new OtherAction(); boolean connect = action.execute(); }

---

En l'état actuel de ce code,

Code:

---

1 2	IAction action = new MyAction(); boolean connect = action.execute();

---

pourrait simplement être remplacé par

Code:

---

boolean connect = new MyAction().execute();

---

et pareil pour OtherAction.

Comme je disais, il n'y a aucun intérêt à abstraire les choses via une interface IAction ici puisque tous les acteurs du système sont toujours au courant de la classe concrète à utiliser (MyAction ou OtherAction).

A moins qu'il y ait d'autres éléments que tu n'as pas donné, j'enlèverais donc complètement la notion de IAction ici. Et ajouter une Factory à l'équation ne ferait que compliquer encore plus un système qui pour l'instant n'a même pas besoin d'abstraction.

Pour rendre les choses vraiment abstraites, il faudrait un unique listener et utiliser les action command (button, listener).

Tu passerais ensuite cette chaîne en paramètre de ta factory. Qui ainsi gagne de l'intérêt en pouvant utiliser une unique instance pour les implémentations stateless plutôt que d'en créer une nouvelle à chaque fois.