Pourquoi appeler une méthode pour mieux définir les variables que de les définir normalement dans le constructeur?

Question

Je faisais un projet dans un livre Java et suis tombé sur cet exemple de code. L'auteur du livre a dit qu'au lieu d'initialiser directement X et Y dans mon constructeur, je pouvais appeler la méthode setLocation() de la classe à la place. Malheureusement, je n'ai plus le livre pour une explication concrète sur la raison pour laquelle c'est mieux. Je ne suis pas trop expérimenté avec Java mais n'est-il pas juste ... plus simple d'attribuer des valeurs directement et ne pas s'inquiéter d'un autre appel de fonction?

//Point constructor, normal way of initializing variables 

private double x; 
private double y; 

Point(double initial_x, double initial_y) 
{ 
this.x = initial_x; 
this.y = initial_y; 
} 

//Point constructor, the other way 

Point(double initial_x, double initial_y) 
{ 
    setLocation(initial_x, initial_y); 
} 


public void setLocation(double newX, double newY) 
{ 
    this.x = newX; 
    this.y = newY; 
} 

Answer 1

Je recommanderais en fait de ne pas appeler des setters dans un constructeur, car l'appel de méthodes redondantes depuis des constructeurs est une mauvaise idée. En outre, l'argument habituel pour les getters/setters est que la logique peut changer, et vous n'aurez pas à changer tout le monde qui accède à vos propriétés. Dans ce cas, cependant, si la logique change, les changements nécessaires sont limités à la même classe.

Answer 2

Parce que les deux instances sont privées vars dans quel exemple, le but de setLocation() dans ce contexte semble permettre à d'autres classes pour modifier les coordonnées de l'objet Point, après il a été initialisé. Et puisque le constructeur aurait fait effectivement la même chose (toujours pour cet exemple simple), le constructeur appelle simplement cette méthode par souci de simplicité.

Answer 3

Vous avez plus de contrôle sur le moment où ils sont réglés.

Answer 4

Même chose que tout le monde dit autre ci-dessus, avec une mise en garde supplémentaire:

, je pouvais voir un argument contre cette pratique si vous aviez besoin d'objets immuables, pour d'autres raisons ou la concurrence. Si vous faites quelque chose où plusieurs threads pourraient agir sur cet objet, le setter va probablement vous causer des ennuis.

Answer 5

S'il y a une certaine logique impliquée dans la définition des membres et que votre classe est mutable (en fournissant une méthode qui se comporte comme appeler le constructeur une seconde fois), il est logique d'utiliser une méthode d'initialisation.

private int width; 
private int height; 
private double diagonal; 

Image(int initial_w, int initial_h) 
{ 
Init(initial_w, initial_h) 
} 

public void Init(int initial_w, initial_h) 
{ 
width = initial_w; 
height = initial.h 
diagonal = Math.sqrt(width*width + height*height); // constructor doesn't need to repeat this line 
} 

Answer 6

Si x et y sont mutable et ont setters non triviales, puis en utilisant le dispositif de réglage pour les initialiser, même dans le constructeur, peut aider à éviter la duplication de code. Dans ce cas, vous pouvez marquer les setters comme final pour empêcher la possibilité qu'une classe dérivée remplace ces méthodes et provoque un comportement inattendu de votre constructeur.

Si les setters sont triviaux (affectation simple sans autre code), alors il n'y a pas beaucoup de raison d'utiliser le setter dans le constructeur.

Si les variables sont immuables, il vaut mieux ne pas avoir de setter du tout et les initialiser directement dans le constructeur.

Answer 7

Cette ressource peut être utile:

http://en.wikipedia.org/wiki/JavaBean

J'ai personnellement constaté que les constructeurs ayant-arg simplifie pas l'injection de dépendance. Par exemple avec Spring IoC, alors que vous pouvez certainement spécifier des arguments constructeur, c'est beaucoup plus simple de ne pas avoir à le faire.

J'ai également trouvé que l'écriture de tests unitaires est plus simple pour la même raison que vous pouvez simplement instancier l'objet que vous voulez, injecter les propriétés requises pour les besoins de votre test et ensuite tester.Avoir un constructeur avec des arguments peut donc vous obliger à configurer les choses avec un objet que vous n'êtes pas particulièrement intéressé par les tests. Cela dit, fournir un constructeur sans argument n'est pas mutuellement exclusif pour fournir des constructeurs pratiques avec des arguments, c'est-à-dire que vous pouvez avoir les deux; assurez-vous simplement que vous disposez d'un système sans-argument pour répondre aux cas d'utilisation décrits ci-dessus.