web-dev-qa-db-fra.com

méthodes d'usine d'instance Vs méthodes d'usine statique

Toutes les méthodes d'usine ne peuvent-elles pas être statiques? Est-ce que quelque chose qui produit un produit a besoin d'un état? Quand est-il approprié d'opter pour une usine d'instance ou une méthode d'usine statique? Pouvez-vous me donner des exemples différenciant les deux?

40
user2434

En supposant que par "méthode d'usine d'instance" vous parlez en fait de la "méthode d'usine" du GoF, le terme "méthode d'usine statique" est décrit par Joshua Bloch dans son livre "Effective Java". Googler autour de moi a atteint ces sites:

J'espère que cela a contribué à rendre la différence un peu plus claire.

Suivant les conseils de Marvo:

  • Méthode d'usine comme indiqué dans GoF:

    définir une interface pour créer un objet, mais laisser les sous-classes décider de la classe à instancier. La méthode Factory permet à une classe de reporter l'instanciation aux sous-classes.

Exemple (code Java):

    public abstract class Product { ... }

    public class ConcreteProduct extends Product { ... }

    public abstract class Creator {
      public void anOperation() { ... product = factoryMethod(); ... }
      public abstract Product factoryMethod();
    }

    public class ConcreteCreator extends Creator {
      public Product factoryMethod() { return new ConcreteProduct(); }
    }
  • Méthode d'usine statique comme indiqué dans Java effectif:

    Une classe peut fournir une méthode d'usine statique publique, qui est simplement une méthode statique qui renvoie une instance de la classe. (...) Un avantage des méthodes d'usine statiques est que, contrairement aux constructeurs, elles ont des noms. (...) Un deuxième avantage des méthodes d'usine statiques est que, contrairement aux constructeurs, elles ne sont pas obligées de créer un nouvel objet chaque fois qu'elles sont invoquées. (...) Un troisième avantage des méthodes d'usine statiques est que, contrairement aux constructeurs, ils peuvent renvoyer un objet de n'importe quel sous-type de leur type de retour. (...) Le principal inconvénient de ne fournir que des méthodes d'usine statiques est que les classes sans constructeurs publics ou protégés ne peuvent pas être sous-classées.

Exemple (code Java):

    public class Boolean {
      ...
      public static Boolean valueOf(boolean b) {
        return b ? Boolean.TRUE : Boolean.FALSE;
      }
      ...
    }
29
Ramon Chiara

Ma préférence actuelle est de rendre les méthodes d'usine non statiques pour faciliter les tests. Vous ne pouvez pas modifier un appel de méthode d'usine statique au moment de l'exécution, alors que si je pouvais fournir une implémentation d'usine à l'objet, je pourrais le tester plus en profondeur car je contrôle mieux le contexte et le graphique de l'objet.

7
Nate W.

Si vous renvoyez un Singleton de votre usine, vous devrez vous assurer que vous n'avez qu'une seule instance, si vous allez créer une nouvelle instance chaque fois que vous appelez l'usine, puis la rendre statique.

2
Bob The Janitor

Cela dépend, par exemple, vous pouvez avoir une usine qui ne produira qu'une certaine quantité d'objets, auquel cas il y aura un état associé. Pour la plupart, les méthodes d'usine peuvent être statiques tant qu'elles ne dépendent pas de variables non statiques (telles que des globaux non statiques et autres) pour leur création. Il a également tendance à différencier différentes usines pour différentes parties d'une application, donc selon qu'il y a un état ou non dans votre usine, c'est ce que vous iriez avec, il n'est pas figé que toutes les méthodes d'usine doivent être statiques, vérifiez quelle situation s'applique à vous et écrivez-le de manière appropriée.

Une autre considération est le mot-clé statique, ce qui fait que tout ce qui est statique n'est instancié qu'une seule fois en mémoire, mais un inconvénient est qu'il réside toujours dans la mémoire de processus (ce qui augmente la taille de l'ensemble de travail). Cela peut être quelque chose que vous ne voulez pas, car votre usine peut avoir une localité très élevée dans certaines régions et sinon cela utiliserait simplement de la mémoire ailleurs, mais c'est généralement un problème d'optimisation qui ne devrait être examiné que si le problème de mémoire la pression dans votre application se pose.

1
Jesus Ramos

Si des instances sont nécessaires auparavant, vous pouvez utiliser la fabrique statique, sinon instancier la fabrique elle-même et la transmettre à votre code.

0
Mad Calm