L'instanciation d'un objet à un constructeur
Il semble que le résultat du code ci-dessous est le même, donc quand dois-je utiliser?
public class Person {
public Person() {
this.family = new Family();
}
Family family;
}
à
public class Person {
Family family = new Family();
}
(un scénario que je pense, c'est quand le fait d'avoir plusieurs constructeurs et nous voulons créer une instance de la famille qu'à l'intérieur de l'un d'entre eux... est-ce le seul cas?)
double possible: stackoverflow.com/questions/3918578/...
OriginalL'auteur Ohad | 2012-02-14
Vous devez vous connecter pour publier un commentaire.
Pour variables de classe [variable statique] vous ne pouvez pas utiliser la première, puisque vous voulez le initializtion ne se produit qu'une fois, et pas à chaque fois que vous appelez votre constructeur.
Pour les variables d'instance, le second est juste un syntatic sucre de la première.
Parfois, vous pourriez ont pour utiliser le deuxième argument du constructeur, qui sont eux - passé à votre constructeur.
OriginalL'auteur amit
Ce dernier permettra de garantir que chaque Personne aura toujours une Famille (awww, n'est-ce pas agréable). Mais dans le premier cas, d'autres constructeurs pourraient être ajoutés par un autre développeur qui laissent une Famille non initialisée. Qui tend à suggérer ce dernier, en version plus courte est préférable. Mais ce n'est pas vraiment vrai, car il pourrait être une condition valide pour modèle d'une Personne n'ayant pas de famille, auquel cas l'initialisation via le constructeur est supérieur parce que vous pouvez passer la valeur null.
La 3ème alternative est l' (plus, soupir) de base POJO style avec setter, dans laquelle la Famille n'est pas initialisé jusqu'à ce qu'un setter est explicitement demandé. La plus belle chose à propos de à l'aide de c'est que vous n'avez pas à fournir une valeur null à un constructeur si vous êtes à la modélisation d'un Orphelin.
Tout dépend de la façon dont vous souhaitez limiter la construction de la Personne.
OriginalL'auteur Kevin Welker
La première méthode vous donne un contrôle personnalisé sur la façon d'initialiser la classe de l'objet que vous avez à traiter avec par constructeur, tandis que la seconde option initialiser la Famille de l'objet de la même façon pour tous les constructeurs.
La première méthode est préférable, car elle permet de prendre une Famille d'objet dans votre constructeur vous permettant de faire des choses comme l'injection de dépendance, qui est généralement bien pratique (et permet de tester plus facilement).
Côté de cela, les deux d'entre eux sont des variables membres (et non statique comme quelqu'un d'autre a dit, vous devez utiliser le mot-clé static). Chaque instance de cette classe contiendra une instance d'une Famille d'objets de cette façon.
Je recommanderais quelque chose comme cela
Edit:
Pour répondre au commentaire qui a été fait au sujet de mon post (qui était exact, un peu), il y a une différence dans laquelle l'ordre des objets sont initialisés. Cependant, le commentaire dit que l'ordre de l'opération est de:
l'initialisation des variables d'instances -> exemple de l'initialiseur -> constructeur
De tests, il semble que cela dépend de se produire en premier dans le code d'initialisation des variables d'instance ou d'instance initialiseurs, et alors que le constructeur est appelé après que les deux d'entre eux. Prenons l'exemple où le constructeur de la Famille de l'objet se contente d'afficher la chaîne de caractères donnée:
résultats de cette sortie lors de la construction d'un objet personne:
Famille: b
Famille:
Famille: c
mais ce code:
résultats de cette sortie lors de la construction d'un objet personne:
Famille:
Famille: b
Famille: c
Merci @BrentWorden, même si l'ordre n'est pas toujours définie de la manière que vous avez spécifié, j'ai fait en sorte de mettre à jour mon post basé sur votre suggestion.
Oui, l'ordre toujours de la manière que j'ai indiquée, car elle est dictée par le Langage Java Spécifications:
Non... il n'est pas. Regardez l'exemple ci-dessus, c'est le code que j'ai couru. La sortie montre clairement que l'ordre d'occurrence des initialiseurs et variable d'instance initialiseurs sont dépendants lorsqu'ils sont rencontrés dans le fichier. Le JSL dit que les objets sont initialisés lorsque l'objet est créé, et de ce que j'ai pu trouver, il n'a pas spécifier un ordre. S'il vous plaît lien doc si vous pouvez le trouver.
Vous corriger. J'étais sûr trop vite dans mon généralisation. Exemple initialise et les variables d'instance sont initialisés dans l'ordre où ils apparaissent dans le fichier source. Constructeur de corps sont invoquées par la suite. java.sun.com/docs/books/jls/third_edition/html/...
OriginalL'auteur dsingleton
Je vous conseille d'utiliser la première quand il s'agit de sous-classement. Considérez ceci:
La deuxième façon de l'initialisation de vous sera toujours possible d'initialiser une nouvelle Famille et ensuite le remplacer si nécessaire. Qui pourrait ne pas être ce que vous voulez, et peut être mauvais pour la performance si ces objets ne beaucoup de travail lors de l'être instanciée.
OriginalL'auteur Daff
Le second style est terrible si vous prévoyez d'étendre la classe (voir Daff de réponse).
Pour les variables d'instance, je crois que c'est plus clair pour l'entretien du programmeur qui est généralement un programmeur junior - pour effectuer tous les niveau de l'instance d'initialisation dans le constructeur. Je recommande une variation de votre option 1.
Je préfère éviter
this
quand il n'est pas nécessaire, car il n'ajoute rien.À l'aide de
this
ajoute nothinig. Il n'y a pas de clarté gain. Si la famille de référence en Personne() n'est pas un membre de référence alors qu'est-elle? Un Lutin?this
est nécessaire uniquement lorsqu'une variable locale (ou paramètre) masque la variable membre, qui est également une mauvaise pratique.OriginalL'auteur DwB
J'aime la deuxième de style mieux. Si vous avez plus d'un constructeur, vous n'avez pas à répéter les initialisations et de ne pas les oublier. Aussi, il indique clairement la façon dont la variable est initialisée. Généralement, lors de la lecture d'un programme et venir à travers une variable, vous devez d'abord aller à sa déclaration. Avec le deuxième style, vous voyez la valeur par défaut. Avec le premier, vous avez besoin de regarder le constructeur.
Ni de calcul supérieure.
OriginalL'auteur Foggzie