java et design pattern factory

Version imprimable

Bonjour,
Dans une méthode java, et à différents endroits, et suivants des règles métiers je fais :
Code:

1 2 3 4 5 ClasseA classeA = new ClasseA (); classeA.setChamps1(parametre1); classeA.setChamps2(parametre2); classeA.setChamps3(parametre3); classeA.setChamps4(parametre4);
je vaudrais refactoriser tout cela , et éviter la duplication du code a chaque fois, dans une factory. Vous savez comment faire ? vous avez une exemple ?
merci

30/09/2009, 12h08
Patriarch24
Tu as plusieurs méthodes :
-> constructeur à paramètres
-> DI (injection de dépendances) : voir des articles sur Spring par exemple
-> Builder (Gof) : permet de construire des objets complexes (littérature importante sur le web)
-> Named Constructor : tu ajoutes méthode statique de construction dans ta classe ; exemple :
Code:

1 2 3 4 5 6 7 8 9 class ClasseA { private ClasseA(/*parametres*/) { // initialisation } public static ClasseA createClasseA(/*parametres*/) { return new ClasseA(/*parametres*/); }
Bon courage !

Merci pour la réponse. Et si je fais uen factory comme ca, c’est bon ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class FactoryClasseA {
 
    public FactoryClasseA () {
        super();
 
    }
 
    private ClasseA ClasseA = null;
 
    public ClasseA getInstance(parameters…) {
 
classeA = new ClasseA ();
classeA.setChamps1(parametre1); 
classeA.setChamps2(parametre2); 
classeA.setChamps3(parametre3); 
classeA.setChamps4(parametre4);
 
        return ClasseA;
 
    }
}

C'est pas une bonne idée, car à chaque fois que tu vas demander une instance, tu vas écraser la précédente ! Tout le monde partagera la même instance changeante...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class FactoryClasseA { public FactoryClasseA () { } public ClasseA getInstance(parameters…) { ClasseA classeA = new ClasseA (); classeA.setChamps1(parametre1); .... return classeA; } }
C'est mieux mais préfère une méthode que j'ai donné au dessus.

01/10/2009, 10h52
snetechen

merci pour ta réponse,
je veux bien utiliser la méthode : -> Named Constructor : tu ajoutes méthode statique de construction dans ta classe ; je crois que ça approche le mieux au pattern Factory. mais le soucis,
dans ma classe principale qui fera appel à la factory pour créer des classesA, je suis pas dans un context statique. or pour appeler la méthode getInstance, je dois me retrouver dans une méthode statique. n'est-ce pas?
01/10/2009, 20h30
Patriarch24

Non c'est le contraire qui n'est pas possible (appeler un membre depuis une méthode statique).

Citation:

Envoyé par Patriarch24

C'est pas une bonne idée, car à chaque fois que tu vas demander une instance, tu vas écraser la précédente ! Tout le monde partagera la même instance changeante...

Je ne suis pas d'accord, ici rien n'est statique, à chaque appel la référence sera écrasée par la nouvelle, c'est vrais, mais le code appelant conservera sa référence propre.

Cependant la factory n'est pas la solution il faudrait utiliser un builder.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class MyBuilderA { public MyClass build(MyClass myObject, <parameters>) { // initialisation return myObject; } } class Main { public static void main(String[] argv) { MyBuilderA builderA = new MyBuilderA(); MyBuilderB builderB = new MyBuilderB(); MyClass mA = builderA.build(new MyClass(), <parameters>); MyClass mB = builderB.build(new MyClass(), <parameters>); } }
A noter qu'on pourrait tout-à-fait utiliser un build static pour éviter d'instancier les builders.

05/10/2009, 02h11
snetechen

Bonjour,
merci pour ta réponse, mais j'ai pas bien saisi la difference entre le fatory et le builder?
tu pourrais me donner un exemple qui montre la difference stp.
merci
05/10/2009, 09h50
Patriarch24

Autant pour moi j'avais cru lire un static :ccool:
Par contre :

Citation:

Cependant la factory n'est pas la solution il faudrait utiliser un builder.

Je ne suis pas d'accord. Si tu as tous les paramètres pour créer immédiatement ton objet, je ne vois pas pourquoi utiliser un monteur. D'autant que l'implémentation que tu donnes n'est pas vraiment celle d'un monteur, du moins au niveau de l'interface : un monteur propose plusieurs méthodes pour construire l'objet au fur et à mesure, et non une seule méthode build, qui correspond juste à un constructeur nommé.
05/10/2009, 10h09
Alain Defrance

Bonjour,

Citation:

Envoyé par Patriarch24

Je ne suis pas d'accord. Si tu as tous les paramètres pour créer immédiatement ton objet, je ne vois pas pourquoi utiliser un monteur. D'autant que l'implémentation que tu donnes n'est pas vraiment celle d'un monteur, du moins au niveau de l'interface : un monteur propose plusieurs méthodes pour construire l'objet au fur et à mesure, et non une seule méthode build, qui correspond juste à un constructeur nommé.

Tout-à-fait, pour le builder le but est en partie de scinder les différentes étapes de la création.

Cependant pour moi (mais je peux être dans le faux), une factory se charge d'instancier, alors qu'un builder initialise.
Il n'est pas rare non plus d'avoir une factory qui appel un builder (ce qui serait pas mal ici puisqu'on éviterait d'instancier dans le code appelant)
05/10/2009, 14h59
Patriarch24

Citation:

ce qui serait pas mal ici puisqu'on éviterait d'instancier dans le code appelant

Attention quand même à la "patternite". Faut pas complexifier le code uniquement pour faire joli. Je maintiens qu'au vu des informations que l'on a, un "constructeur nommé" fera l'affaire.
05/10/2009, 16h28
Alain Defrance

Tu as sans doute raison, inutile de sortie le bazooka pour tuer une fourmis :mouarf:
05/10/2009, 21h21
Patriarch24

J'avais ça derrière la tête en effet :yaisse1: