C’est une mauvaise habitude de faire un setter retourne « this » ?

Question

Est-ce une bonne ou une mauvaise idée de faire des setters de java retour "ce"?

public Employee setName(String name){
   this.name = name;
   return this;
}

Ce modèle peut être utile parce que vous pouvez enchaîner les setters comme ceci:

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

au lieu de cela:

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

...mais ça va à l'encontre de la norme de la convention. Je suppose qu'il pourrait être utile, juste parce que cela peut faire que le setter de faire autre chose d'utile. J'ai vu ce motif est utilisé certains endroits (par exemple JMock, JPA), mais il semble rare, et seulement généralement utilisé pour définir les Api où ce modèle est utilisé partout.

Mise à jour:

Ce que j'ai décrit est évidemment valable, mais ce que je suis à la recherche de quelques réflexions sur que ce soit généralement acceptable, et s'il y a des pièges ou les meilleures pratiques. Je sais que sur le Générateur de modèle mais il est un peu plus impliqué alors ce que je viens de décrire - comme Josh Bloch décrit il y est associé à un Constructeur statique de la classe pour la création d'objet.

Answer 1

Il n’est pas mauvaise pratique. C’est une pratique de plus en plus fréquente. La plupart des langues ne vous obligent pas à traiter de l’objet retourné si vous ne voulez donc il ne change pas la syntaxe d’utilisation « normale » setter mais permet aux poseurs de chaîne ensemble.

Ceci est communément appelé un modèle de générateur ou une interface fluent.

Il est également fréquent dans l’API Java :

Answer 2

Pour résumer:

• il a appelé à une "interface fluide", ou "le chaînage de méthode".
• ce n'est pas "standard" de Java, même si vous ne la voir de plus une plus ces jours-ci (fonctionne très bien en jQuery)
• elle viole le JavaBean spec, donc il va rompre avec divers outils et des bibliothèques, en particulier JSP constructeurs et au Printemps.
• il peut empêcher certaines optimisations que la JVM feriez normalement
• certaines personnes pensent qu'il nettoie code, d'autres pensent que c'est "horrible"

Un couple d'autres points ne sont pas mentionnés:

• Cela viole le principe que chaque fonction devrait faire un (et un seul) de la chose. Vous peut ou peut ne pas croire à cela, mais en Java je crois qu'il fonctionne bien.

• IDEs ne vont pas générer ces pour vous (par défaut).

• J'ai enfin, voici un monde réel point de données. J'ai eu des problèmes en utilisant une bibliothèque construite comme cela. Hibernate query builder est un exemple de cela dans une bibliothèque existante. Depuis Requête* méthodes retournent des requêtes, il est impossible de le dire juste en regardant la signature de la façon de l'utiliser. Par exemple:

  Query setWhatever(String what);
  

• Il introduit une ambiguïté: la méthode de modifier l'objet courant (le patron) ou peut-être la Requête est vraiment immuable (très populaire et précieux, par exemple), et la méthode est de retour une nouvelle. Il fait juste de la bibliothèque plus difficile à utiliser, et beaucoup de programmeurs de ne pas exploiter cette fonctionnalité. Si les poseurs ont été setters, il serait plus claire de la façon de l'utiliser.

Answer 3

Je préfère utiliser « avec » méthodes pour cela :

Donc :

Answer 4

Je ne pense pas qu'il y a de quoi que ce soit incorrect avec elle, c'est juste une question de style. C'est utile lorsque:

• Vous avez besoin de définir de nombreux domaines à la fois (y compris la construction)
• vous savez les champs que vous devez définir au moment où vous avez écrit le code, et
• il existe de nombreuses combinaisons différentes pour les champs que vous souhaitez définir.

Des Alternatives à cette méthode pourrait être:

1. Un mega constructeur (inconvénient: vous risquez de passer beaucoup de zéros ou des valeurs par défaut, et il devient difficile de savoir quelle valeur correspond à quoi?)
2. Plusieurs constructeurs surchargés (inconvénient: devient lourd une fois que vous avez plus que quelques-uns)
3. Usine/méthodes statiques (inconvénient: la même que les constructeurs surchargés - devient lourd une fois il n'y a plus que quelques-uns)

Si vous allez seulement à définir quelques propriétés en même temps je dirais que c'est pas la peine de revenir 'cette'. Il a certainement tombe vers le bas si vous décidez plus tard de retourner quelque chose d'autre, comme un état/indicateur de réussite ou d'un message.

Answer 5

Si vous ne voulez pas retourner `` de l’accesseur Set, mais ne voulez pas utiliser la deuxième option, vous pouvez utiliser la syntaxe suivante pour définir les propriétés :

Soit dit en passant, je pense que ses un peu plus propre en c# :