Statique usine méthodes vs Instance (normal) les constructeurs?

Dans une langue où les deux sont disponibles, préféreriez-vous voir un exemple de constructeur ou une méthode statique qui renvoie une instance?

Par exemple, si vous êtes à la création d'un String à partir d'un char[]:

String.FromCharacters(chars);
new String(chars);

Ont ajouté "méthode" pour le titre, parce que sinon, il suggère que le choix est entre une instance constructeur ou un constructeur statique. (Le texte est clair, mais le titre a provoqué une certaine "Hein?" question dans mon esprit 🙂
Votre modification a été annulée 🙂
Va le refaire ensuite, l'examen de la question n'est pas à propos de constructeurs statiques...

InformationsquelleAutor Dan Goldstein | 2008-10-11

55

Dans Efficace Java, 2nd edition, Joshua Bloch certainement recommande à l'ancienne. Il y a quelques raisons que je me souvienne, et sans doute certains je ne peux pas:
- Vous pouvez donner la méthode un nom significatif. Si vous avez deux manières de construire une instance à la fois de prendre un int, mais ont des significations différentes pour que int, à l'aide d'une méthode normale fait l'appel de code beaucoup plus lisible.
- Un corollaire de la première, vous pouvez avoir différentes méthodes de fabrique avec la même liste de paramètres
- Vous pouvez retourner la valeur null pour "potentiellement échec prévisible" des cas, alors qu'un constructeur toujours soit de retourner une valeur ou lever une exception
- Vous pouvez retourner un type autre que le déclaré (par exemple, le retour d'une classe dérivée)
- Vous pouvez l'utiliser comme une usine, peut-être retourner une référence au même objet plusieurs fois
Les inconvénients:
- Ce n'est pas comme idiomatiques, actuellement, les développeurs sont plus habitués à voir des "nouveaux"
- Si vous voyez un "nouveau" vous savoir vous obtenez une nouvelle instance (modulo le curiosité je l'ai mentionné récemment)
- Vous avez besoin pour faire les bons constructeurs disponibles pour les sous-classes
- En C# 3, constructeur appels sont en mesure de définir des champs/propriétés dans un boîtier compact avec objet d'initialiseur expressions; la fonction ne s'applique pas aux méthodes statiques
- La lecture de l'Article 2 dans Efficace Java, on peut facilement avoir l'impression que Joshua Bloch est en faveur d'une utilisation statique de l'usine de méthodes comme le choix par défaut. Mais je ne pense pas que ce soit réellement le cas, ou, au moins, il n'était pas en 2002 quand il a fait cette interview avec Bill Venners que j'ai cité dans ma réponse plus bas.
- re. votre point sur le c#, j'ai utilisé ce modèle dans le passé; Voir ma réponse ici, qui propose une solution de contournement pour le compact initialiseur de problème (enfin, la remplace par quelque chose qui est aussi compact de toute façon!) stackoverflow.com/a/10171659/705589
InformationsquelleAutor Jon Skeet
22

J'écris un constructeur lors de la création de l'instance n'a pas d'effets secondaires, c'est à dire quand la seule chose que le constructeur est en train de faire l'initialisation de propriétés. - Je écrire une méthode statique (et faire le constructeur privé) si la création de l'instance ne fait quelque chose que vous ne serait pas normalement attendre d'un constructeur à faire.

Par exemple:
```
public class Foo
{
   private Foo() { }

   private static List<Foo> FooList = new List<Foo>();
   public static Foo CreateFoo()
   {
      Foo f = new Foo();
      FooList.Add(f);
      return f;
   }
}
```
Parce que j'adhère à la présente convention, si je vois
```
Foo f = Foo.CreateFoo();
Bar b = new Bar();
```
lors de la lecture de mon code, j'ai un ensemble très différent des attentes à propos de ce que chacune de ces deux lignes est en train de faire. Ce code n'est pas de me dire ce que c'est qui rend la création de Foo différent de la création d'un Bar, mais il me dit que j'ai besoin de regarder.
- Bon point sur le traitement anormal. Personnellement, je n'aime pas l'idée d'utiliser une méthode statique à la place d'un constructeur par défaut. C'est répétitif et va à contre-courant de la langue. Je préfère de refactoriser le traitement anormal et d'utiliser le nouveau mot-clé, si possible.
- Ce n'est pas invalider la section "utilisation statique par défaut" argument. Vous pouvez toujours faire la différence entre un constructeur statique d'un constructeur statique (que vous avez besoin de regard) en utilisant les conventions de nommage. E. g. Foo.New() que le défaut de remplacement pour new, et Foo.FromAbc() etc pour le spécial ceux.
InformationsquelleAutor Robert Rossney
10

J'ai travaillé sur une API publique récemment, et j'ai été à l'agonie sur le choix de la statique de l'usine de méthodes contraceptives constructeur. Statique méthodes de fabrique certainement faire sens dans certains cas, mais dans d'autres, il n'est pas clair et je ne suis pas certain que la cohérence avec le reste de l'API est une raison suffisante pour inclure plus de constructeurs.

De toute façon, je suis tombé sur un citation de Bill Venners interview avec Josh Bloch que j'ai trouvé utile:

Lorsque vous écrivez une classe, vous pouvez
exécutez le mon livre la liste de la
avantages de la statique des usines de plus de
les constructeurs publics. Si vous trouvez que
un nombre important de ces
avantages s'appliquent effectivement dans votre
cas, alors vous devriez aller avec les
statique des usines. Sinon, vous devriez
aller avec les constructeurs.

Certains ont été déçus de trouver
que des conseils dans mon livre. Ils l'ont lu
et dit, "Vous avez soutenu fortement
pour le public static usines que nous
faut juste les utiliser par défaut." J'
pense que le seul vrai inconvénient dans
ce faisant, c'est que c'est un peu
déconcertant pour les personnes qui sont utilisés
à l'aide de constructeurs pour créer leur
objets. Et je suppose qu'il fournit un
un peu moins d'un repère visuel dans le
programme. (Vous ne voyez pas le nouveau
mot-clé.) C'est également un peu plus
difficile de trouver de la statique des usines en
la documentation, parce que Javadoc
des groupes de tous les constructeurs ensemble.
Mais je dirais que tout le monde devrait
envisager statique des usines de tous les
temps, et de les utiliser quand ils sont
approprié.

Avoir lu cette citation, et l'étude d'Uri mentionné*, je me sens enclin à pencher en faveur des constructeurs, sauf s'il existe des raisons impérieuses de le faire autrement. Je pense statique méthode de fabrique, sans bonne raison est probablement juste une complexité inutile et plus-ingénierie. Bien que je pourrais bien changer d'avis et de nouveau d'ici demain...

*Malheureusement, cette étude se focalise moins sur la statique de l'usine de méthodes et de plus en plus sur le modèle de fabrique (où une usine distincte de l'objet existe pour créer de nouvelles instances), donc je ne suis pas sûr que l'on peut vraiment en tirer la conclusion que statique usine méthodes de confondre de nombreux programmeurs. Bien que l'étude ne me donnent l'impression que, souvent, ils le feraient.
- +1 pour la profondeur-ness. Besoin de plus upvotes.
InformationsquelleAutor MB.
9

Si votre objet est immuable, vous pouvez peut-être utiliser la méthode statique de retourner les objets mis en cache et vous épargner de l'allocation de mémoire et de traitement.

InformationsquelleAutor Dan Goldstein
7

Il y a un article à partir de la CISP'07 qui a étudié la facilité d'utilisation des constructeurs vs usine de modèles. Tandis que je préfère usine de modèles, l'étude a montré que les développeurs ont été plus lents à trouver une bonne méthode de fabrique.

http://www.cs.cmu.edu/~NatProg/documents/Ellis2007FactoryUsability.pdf
- C'est une bonne réponse, malheureusement. Je suis prête à faire de répartition sans le "nouveau" mot-clé, mais la détection est assez important. J'avais de la haine pour quelqu'un pour faire leur propre traitement pour créer un théorique objet String parce qu'ils n'ont pas de voir un constructeur.
- Je suis d'accord, le problème de savoir comment garantir aux gens de découvrir une statique est important. La part de l'auteur de ce papier est actuellement à la construction d'un outil pour que, dans le cadre de son travail de Doctorat, il va être intéressant de voir où cela finit.
- Bien sûr, c'est plus lent actuellement parce qu'il n'y a pas encore de normes corps, créant correcte des conventions de nommage pour les constructeurs statiques. Voilà qui contraste avec le bien connu convention de new normal des constructeurs.
InformationsquelleAutor Uri
2

Méthode Statique. Ensuite, vous pouvez retourner une valeur null, plutôt que de lancer une exception (à moins qu'un type de référence)

InformationsquelleAutor Darren Kopp
2

Je préfère instance constructeur, juste parce que cela fait plus de sens pour moi, et il y a moins de risque d'ambiguïté avec ce que vous essayez d'exprimer (c'est à dire: que si FromCharacters est une méthode qui prend un seul caractère). Certes subjective, mais.

InformationsquelleAutor Nick
2

Personnellement, je préfère voir un constructeur normal, puisque contructors devraient être utilisés pour construire. Cependant, si il y a une bonne raison à pas utiliser un, c'est à dire si FromCharacters déclare explicitement qu'il n'alloue pas de mémoire, il en vaudrait la peine. La "nouvelle" dans l'invocation a un sens.

InformationsquelleAutor nimish
2

Il dépend. Pour les langues dans lesquelles l'aide d'une instance constructeur est "normal", je voudrais généralement utiliser un, sauf si j'avais de bonnes raisons de ne pas. Il suit le principe de moindre surprise.

Par le chemin, vous avez oublié un autre cas courant: null/constructeur par défaut couplé avec une méthode d'initialisation.
- Oui, je n'avais pas pensé à ce cas. Je pense que c'est inférieur aux deux présenté parce qu'il a besoin de lignes de code. J'ai pu modifier la question de l'inclure si.
- Qu'entendez-vous par "null constructeur jumelé avec initialisation"?
- Un constructeur qui ne prend aucun paramètre et, peut-être, seulement alloue de la mémoire en laissant l'objet non initialisé. Couplé avec une méthode d'initialisation(s). Si je me souviens bien, c'est la façon dont les objets Ruby sont mis en œuvre dans C.
InformationsquelleAutor ejgottl
1

Comme Jon Skeet paraphrasé Josh Bloch, il y a un certain nombre de raisons pour lesquelles une statique usine méthode est préférable à un constructeur, dans de nombreux cas. Je dirais que si la classe est un simple pas cher le programme d'installation ou d'utilisation compliquées, séjour avec le idiomatiques constructeur. Moderne Jvm faire l'objet de création extrêmement rapide et bon marché. Si la classe peut être sous-classé ou vous êtes en mesure de le faire immuables (un gros avantage pour la programmation simultanée, qui va seulement pour obtenir plus importantes), puis aller avec la méthode de fabrique.

Une astuce de plus. Ne pas le nom de la méthode de fabrique Foo.new* ou Foo.create*. Une méthode avec ces noms doit toujours renvoyer une nouvelle instance, et ce faisant on oublie un des grands avantages de la méthode de fabrique. Une meilleure convention de nommage est Foo.of* ou Foo.for*. Le Google Goyave bibliothèque (anciennement Google Collections de la Bibliothèque) fait un excellent travail de ce, à mon humble avis.
- Pourriez-vous développer un peu sur pourquoi of* et for* sont meilleurs noms que new* ou create*? Nommant les choses, à juste titre, est important pour moi, donc j'aimerais apprendre quelque chose de nouveau ici.
- Si vous utilisez de nouveaux* ou créer* vous êtes "obligés" de donner une nouvelle instance, tout en utilisant les dénominations proposées vous permet de réutiliser l'existant.
InformationsquelleAutor Dov Wasserman
0

Bien sûr, il y a plusieurs avantages de la statique des méthodes fabrique plus de constructeurs.
1. usine méthodes nous aider à écrire flexible code. Alors que les constructeurs de fait étroitement couplées.
2. Statique usine méthodes d'améliorer la lisibilité puisque ceux-ci vous permettent de créer différentes instances.
3. Vous pouvez retourner un objet mis en cache. Par exemple getInstance() en Singleton.
InformationsquelleAutor Sumanth Varada

Vous devez vous connecter pour publier un commentaire.