Quand utiliser un Constructeur et quand utiliser la méthode getInstance () (statique usine méthodes)?

Question

1. Quand et comment doit-on utiliser un Constructeur

   Foo bar = new Foo();
   

2. Et Quand et comment doit-on utiliser getInstance() (statique méthodes de fabrique)

   Foo bar = Foo.getInstance();
   

Quelle est la différence entre ces deux-là, je l'utilise toujours la 1ère méthode, mais quand utiliser la 2ème méthode??

Answer 1

Tout le monde semble se concentrer sur les singletons alors je pense que la question est en fait environ constructeur vs statique méthodes de fabrique.

C'est en fait l'Élément 1: Envisager statique usine méthodes à la place des constructeurs de Efficace Java par Joshua Bloch:

Article 1: Envisager statique usine méthodes à la place des constructeurs

La façon normale pour une classe pour permettre un client pour obtenir une instance de lui-même est de fournir un constructeur public. Il y a une autre technique qui devrait être une partie de chaque programmeur boîte à outils. Une classe peut fournir à un public statique méthode de fabrique, qui est simplement une méthode statique qui renvoie un instance de la classe. Voici un simple exemple d' Boolean (la boite primitives de la classe pour le type primitif boolean). Cette méthode se traduit par une boolean valeur primitive dans un Boolean référence de l'objet:

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

Notez qu'un statique méthode de fabrique est pas la même que la Méthode de Fabrique modèle à partir de Modèles de Conception [Gamma95, p. 107]. La statique de l'usine méthode décrite dans cet article n'a pas de d'équivalent direct dans la Conception Les schémas.

Une classe peut fournir à ses clients avec statique usine méthodes à la place de, ou en plus, les constructeurs. Offrant une statique de la méthode de fabrique au lieu d'un constructeur public a à la fois des avantages et des inconvénients.

Avantages (citant le livre):

• L'un des avantages de la statique des méthodes de fabrique, c'est que, contrairement aux constructeurs, ils ont des noms.
• Un deuxième avantage de la statique des méthodes de fabrique, c'est que, contrairement aux constructeurs, ils ne sont pas tenus de créer un nouvel objet à chaque fois qu'ils sont invoqués.
• Un troisième avantage de la statique des méthodes de fabrique, c'est que, contrairement aux constructeurs, ils peuvent retourner un objet de n'importe quel sous-type de leur type de retour.
• Un quatrième avantage de statique usine méthodes est qu'elles permettent de réduire le niveau de verbosité de la création paramétrée type de cas.

Les inconvénients (toujours en citant le livre):

• Le principal inconvénient de ne fournir que de la statique de l'usine de méthodes est que des classes sans public ou protégé les constructeurs ne peuvent pas être sous-classé.
• Un deuxième inconvénient de la statique des méthodes de fabrique, c'est qu'ils ne sont pas facilement reconnaissable par rapport aux autres méthodes statiques.

Answer 2

Vous avez deux questions: quand devrais-je appeler un getInstance() méthode, et quand dois-je créer ?

Si vous êtes de décider d'appeler un getInstance() méthode, c'est facile. Vous avez juste besoin de lire la documentation de classe pour savoir quand vous devez l'appeler. Par exemple, NumberFormat fournit un constructeur et un getInstance() méthode; l' getInstance() méthode vous donnera un localisée NumberFormat. Pour Calendar, d'autre part, le constructeur est protégé. Vous avez à appeler getInstance() pour l'obtenir.

Si vous êtes de décider de créer un getInstance() méthode, vous devez décider ce que vous essayez d'accomplir. Soit vous ne voulez les gens à appeler votre constructeur (vous êtes en train de créer un singleton ou une usine), ou vous n'avez pas l'esprit (comme en NumberFormat - dessus, où ils sont l'initialisation de certains objets pour la commodité de l'appelant).

---

Longue histoire courte? Ne vous inquiétez pas au sujet de la création d' getInstance() méthodes dans votre propre code. Si le temps se pose lorsque qu'ils peuvent être utiles, vous savez. Et en général, si vous pouvez appeler un constructeur de la classe, vous êtes probablement censé faire que, même si la classe fournit un getInstance() méthode.

Answer 3

L'utilise pour getInstance méthodes:

• Si vous voulez contrôler ou limiter la construction, par exemple Singleton
• mettre en œuvre modèle de Fabrique, par exemple, DriverManager.getConnection
• Lorsque vous souhaitez offrir un meilleur nom à la façon dont l'instance est construit (constructeurs doivent avoir le même nom que le nom de la classe), l'extraction de la NumberFormat usine méthodes getCurrencyInstance, getIntegerInstance et d'autres comme des exemples de cette.

Mais la plupart du temps, votre objet sera un simple POJO et l'usage du public, les constructeurs est la plus pratique et la solution la plus évidente.

U1: getInstance D'une Autre Classe

Pour retourner une instance d'une autre classe:

public class FooFactory {
    public static Foo getInstance() {
        return new Foo();
    }
}

NumberFormat.getInstance méthodes de faire ce qu'ils ont fait retourner les instances de l' DecimalFormat.

U2: Singleton Problèmes

Le pattern singleton restreint de nombreux avantages de la programmation orientée objet. Les Singletons ont généralement les constructeurs privés, par conséquent, vous ne pouvez pas les prolonger. Comme vous aurez accès via sa méthode getInstance et de ne pas faire référence à une interface, vous ne serez pas en mesure de l'échanger pour une autre mise en œuvre.

Answer 4

Si vous pouvez utiliser les deux, puis il sonne comme un mal mis en œuvre le pattern singleton.

Utiliser la deuxième option si vous avez l'intention de n'avoir qu'une seule instance de la classe dans votre système et faire le constructeur privé alors.

Utiliser le premier à permettre la construction de plusieurs objets de la classe.

MAIS ne donnez pas à votre classe les deux possibilités.

Attention à ne pas sur-utiliser les singletons, ne les utiliser que si vraiment qu'une seule instance doit exister dans le système, sinon vous permettrait de limiter les possibilités de réutilisation de votre classe dans d'autres projets. Il semble intéressant de pouvoir appeler getInstance de partout dans votre projet, mais qui rend difficile de savoir qui est le propriétaire de cette instance: personne et/ou de tous les. Si vous avez beaucoup de singletons dans un projet, vous pouvez parier que le système est mal conçu (en général). Les Singletons doit être utilisé avec précaution, les mêmes conseils que pour les variables globales s'appliquent.

Answer 5

Un seul cas dans lequel je préfère toujours un statique usine plus régulière d'un constructeur, c'est quand je sais que la construction de l'objet sera slowish. Je ne initialisation simples sur le constructeur, mais si j'ai besoin de créer quelque chose de lourd, je vais utiliser une méthode statique et de documenter le comportement.