Utilisation du constructeur privé pour empêcher l'instanciation de la classe?

Question

En ce moment je pense à ajouter un constructeur privé à une classe qui ne contient que String constantes.

public class MyStrings { 
    // I want to add this: 
    private MyString() {} 

    public static final String ONE = "something"; 
    public static final String TWO = "another"; 
    ... 
} 

Y at-il des performances ou mémoire frais généraux si j'ajoute un constructeur privé à cette classe pour empêcher quelqu'un pour instancier?

Pensez-vous qu'il est nécessaire du tout ou que les constructeurs privés à cet effet sont une perte de temps et l'encombrement de code?

MISE À JOUR

Je vais pour une classe finale avec constructeur privé et un javadoc descriptif pour la classe. Je ne peux pas utiliser ENUM (que je préfère) car je suis coincé sur Java 1.4 pour le moment. Ce serait ma modification:

/** 
* Only for static access, do not instantiate this class. 
*/ 
public final class MyStrings { 
    private MyString() {} 

    public static final String ONE = "something"; 
    public static final String TWO = "another"; 
    ... 
} 

Answer 1

L'utilisation du constructeur privé pour empêcher l'instanciation de la classe?

Il y a plusieurs façons dont vous pouvez penser des utilisateurs empêchant de la Instantiations dans le but de créer les Constantes

1. Comme vous l'avez mentionné une classe avec les constructeurs privés et a toutes les cordes Constantes, est l'un ainsi, même il ia une surcharge, qui peut être négligeable
2. que vous pouvez créer une classe avec final Modidifier et définir votre chaîne constantes
3. vous pouvez utiliser la classe abstraite avec la chaîne Constantes
4. Vous pouvez définir les constantes de chaîne dans les fichiers de propriétés et y accéder, cela réduira définitivement la mémoire et augmentera la flexibilité de votre code.

Answer 2

Un constructeur public synthétique aurait été généré de toute façon. Donc non.

vraiment quelques octets sur des centaines de millions à l'exécution ne va pas faire beaucoup de différence.

Je suggère également faire la classe final et juste pour être complet ont le constructeur lancer une exception.

Si vous voulez le code source laconique, vous pouvez créer un ENUM sans valeurs. Cela pourrait causer une certaine confusion avec les programmeurs débutants.

Answer 3

Je préfère utiliser une énumération pour conserver cette chaîne. Cela garantirait que, quel que soit l'endroit où vous utilisez ces chaînes, vous ne soyez transmis que dans l'une des chaînes autorisées.

Answer 4

C'est la bonne façon de stocker certaines constantes, comme le suggère dans Effective Java (2e éd.), Point 19.

Answer 5

Si votre classe ne compte que des membres statiques, alors il n'y a pas besoin d'avoir un privé ou constructeur public. Tous les membres sont accessibles même sans objet. En fait, je trouve déroutant d'avoir un constructeur dans un tel cas.

Answer 6

Si vous ne serez pas à quiconque de faire un objet de la classe que vous pouvez faire ce abstrait comme celui-ci

public abstract class MyStrings { 
    public static final String ONE = "something"; 
    public static final String TWO = "another"; 
} 

et accéder à vos variables statiques comme celui-ci

String val1 = MyStrings.ONE; 
String val2 = MyStrings.TWO; 

Je pense Ce serait une meilleure solution.

Answer 7

Vous pouvez ajouter un constructeur privé, mais il existe deux autres options.

Dans la même situation, j'utiliseraient un recenseur.S'il est logique de votre implémentation, vous pouvez utiliser à la place, si elle est public ou private dépend de l'endroit où vous devez l'utiliser:

public enum MyStrings { 

    ONE ("something"), 

    TWO ("something else"); 

    private String value; 

    private MyStrings(String str) { 
    this.value = str; 
    } 

} 

Une autre option serait de le mettre dans une classe, ceux qui ne peuvent pas abstract instancier:

public abstract MyStrings { 

    public static final String STUFF = "stuff"; 
    public static final String OTHER = "other stuff"; 
} 

accès pour les travaux recenseur et classe abstraite comme la mise en œuvre que vous avez présenté:

MyStrings.STUFF 

Answer 8

Il n'y a pas de surcharge de performances ou de mémoire si vous ajoutez un constructeur privé dans ce cas. De plus, il n'est pas nécessaire puisque vos variables statiques publiques sont partagées entre toutes les instances de votre objet.

Answer 9

Pour moi, la meilleure explication est efficace livre Java: Point 4: Faire respecter noninstantiability avec un constructeur privé (See more)

En résumé:

• constructeur privé est due Les classes d'utilitaire n'ont pas été conçues pour être instanciées, de même qu'une décision de conception. (AUCUNE performance ou charge de mémoire)
• La création d'un résumé de classe ne fonctionne pas car il peut être sous-classé puis instancié.
• Avec une classe abstraite, l'utilisateur peut penser que la classe est destinée à l'héritage.
• La seule façon de s'assurer qu'aucune instanciation est d'ajouter un private constructor qui garantit que le constructeur par défaut n'est pas généré.
• Le constructeur privé empêche l'héritage car le super constructeur ne peut pas être appelé (donc il n'est pas nécessaire de déclarer la classe comme finale)
• Lancer une erreur dans le constructeur privé évite de l'appeler dans la classe.

definetively, la meilleure façon serait quelque chose comme suivant:

public class MyStrings { 

    private MyStrings() { 
     throw new AssertionError(); 
    } 
     ... 
}