Est-ce une mauvaise pratique de faire un setter retour “ce”?

Est-il 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.

Depuis que j'ai vu ce modèle il y a un moment, je le fais dans la mesure du possible. Si une méthode n'est pas explicitement besoin de retourner quelque chose à faire son travail, elle revient aujourd'hui this. Parfois, j'ai même de modifier la fonction de sorte qu'au lieu de retourner une valeur, il fonctionne sur un membre de l'objet, juste pour que je puisse le faire. C'est merveilleux. 🙂
Pour télescopique setters retour auto et dans les constructeurs, je préfère utiliser avec name(String nom) au lieu de setName(String name). Comme vous l'avez souligné une pratique courante et de l'attente pour setter est de retour void. "Non standard" poseurs ne peut pas bien se comporter avec les cadres existants, par exemple les gestionnaires de l'entité JPA, Spring, etc.
Veuillez introduire des sauts de ligne avant chaque invocation 🙂 Et configurer votre IDE ou obtenir un bon un, si ce n'est pas le respect de cette.
Largement utilisé frameworks (Spring et Hibernate par exemple) de manière stricte (au moins ils ont utilisé pour) adhérer à void-setters convention
Voir aussi stackoverflow.com/questions/5741369/...

InformationsquelleAutor Ken Liu | 2009-08-28

72

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 devez définir le nombre de champs à la fois (y compris la construction)
- vous savez quels domaines vous devez définir au moment où vous avez écrit le code, et
- il y a 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.
- et bien, vous n'avez pas de retour de tout, d'un poseur de toute façon, par convention.
- Peut-être pas au début, mais un setter n'est pas nécessairement conserver son but d'origine. Ce que l'habitude d'être une variable peut changer dans un état qui englobe plusieurs variables ou avoir d'autres effets secondaires. Certains poseurs peut retourner une valeur précédente, d'autres peuvent retourner un indicateur d'échec si la panne est trop commun pour une exception. Cela soulève un autre point intéressant cependant: que faire si un outil/framework que vous utilisez ne reconnaît pas votre setters quand ils ont des valeurs de retour?
- bon point, en faisant cela rompt avec le "Java bean" convention pour les getters et les setters.
- Ne casser "Java Bean" convention de causer des problèmes? Sont les bibliothèques qui utilisent le "Java Bean" convention de regarder le type de retour ou tout simplement les paramètres de la méthode et le nom de la méthode.
- malheureusement, je suis en train de travailler dans un data-bean-centric (Otd, DAOs) env de cette façon, et maintenant j'ai vous ne pouvez pas bénéficier de la AutoBean (code.google.com/p/google-web-toolkit/wiki/AutoBean#Quickstart) la fonctionnalité qui ne peut pas gérer cette situation de non-Bean-Standard out-of-the-box. Donc j'ai peur de meuble a l'avantage de moins de code réutilisable ici :-(. Mais peut-être qu'il y a un chemin avec elle ... je vais voir.
- c'est pourquoi le Constructeur modèle existe, les poseurs ne devrait pas retourner quelque chose, au lieu de cela, créer un constructeur, si son besoin regarde mieux et prend moins de code 🙂
- vous pouvez avoir spéciale setter qui pourrait prendre une Carte de propriétés (nom et valeurs). Puis, à l'intérieur de la méthode, vous pouvez utiliser la réflexion pour invoquer approprié setters. Cette approche peut ne pas fonctionner lorsque vous avez quelques surchargé organismes de normalisation et de profiter de moment de la compilation, la vérification est également perdu.
- Pour moi, il semble que le nom de la fonction se trouve si je suis de retour avec quoi que ce soit. Si il est de retour avec un objet, puis le nom de ce qui devrait être setPropertyAndGetObject(); a une chose, de définir une propriété. Bien sûr, je n'ai pas besoin de savoir comment le setter est implémente cet ensemble par exemple $A->setFullName($firstName, $lastName); pouvez faire un peu de logique, par exemple, dans les différents pays, le nom de famille est le premier et premier nom est le deuxième. Mais il faire une seule chose: définit le nom complet.
- Je ressens votre douleur...Mais si l'alternative est d'avoir un mega-constructeur je peux vivre avec ça... de toute façon, votre exemple n'est pas si clair pour mee:: lorsque vous, moi, ou n'importe qui d'oreilles à propos de 'setter' pense 'getters et setters", et pas sur "calculer la bonne stratégie pour créer de la valeur et de définir': Votre exemple devrait être: setFullName(calcFullName(prénom, nom)). Pour moi, avoir des Setters un Getters une définition claire dans mon esprit, la question devrait être: le fait de retourner " ce " dans le poseur de changer cette définition de façon dramatique?
- De retour this est fondamentale pour la Builder modèle. Mais, de retour this est aussi, de par sa conception avec un état de fonctionnement. Il n'y a pas de one-size-fits-all. Faveur de l'immuabilité. Le point de l'ensemble d'un constructeur (en général) est de faire de la construction d'un objet immuable failsafe
InformationsquelleAutor Tom Clift
98

Ce n'est pas une mauvaise pratique. Il est de plus en plus une pratique courante. La plupart des langues ne vous oblige pas à traiter avec l'objet retourné si vous ne voulez pas de sorte qu'il ne change pas "normal" de poseur de syntaxe d'utilisation mais qui permet à la chaîne des setters ensemble.

Ce qui est communément appelé un générateur de motif ou un interface fluide.

Il est également fréquent dans l'API Java:
```
String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();
```
- Il est souvent utilisé dans les constructeurs, mais je ne dirais pas "c'est ... appelé un Générateur de modèle".
- C'est drôle pour moi que certains de la raison d'être couramment interfaces, c'est qu'ils rendent le code plus facile à lire. Je pouvais voir qu'il est plus commode d'écrire, mais ça me frappe comme étant plus difficile à lire. C'est le seul désaccord que j'ai avec elle.
- Probablement l'incarnation ultime de fluent interfaces LINQ
- Il est également connu comme le train-épave antipattern. Le problème est que quand un pointeur null trace de pile d'exception contient une ligne comme ceci, vous n'avez aucune idée de qui invocation retourné null. Cela ne veut pas dire que le chaînage doit être évité à tous les frais, mais méfiez-vous des mauvais bibliothèques (esp. fait maison).
- Le générateur de modèle, même s'il a la même apparence qu'un "accident de train," ne viole pas la Loi de Déméter. Est-il vraiment une épave de train?
- Conrad - la loi de Déméter est pas pertinente ici (nous ne parlons pas d'intermédiaires) - si il jette NPE vous ne connaissez pas l'instruction qui a provoqué et c'est tout. Il existe de nombreux exemples de enchaînés l'API (Easymock/Mockito vient à l'esprit), mais j'ai vu des assez horribles abominations, et ils sont une douleur à déboguer et de soutien.
- aslong que vous limiter à un retour de ce il ne serait jamais un problème (seul le premier invokation de jeter des NPE)
- Je pense que l'argument n'est pas comme beaucoup comme il rendre le code plus facile à lire, mais qu'il est plus facile de écrire et les auteurs thererfore préférant et, implicitement, considérant qu'il est plus facile à lire.
- il est plus facile à écrire ET à lire supposé que vous avez mis mais les sauts de ligne et le retrait où la lisibilité subirait le contraire! (parce qu'il évite redondant encombrement de la répétition du code comme bla.foo.setBar1(...) ; bla.foo.setBar2(...) quand vous pourriez écrire bla.foo /* newline indented */.setBar1(...) /* underneath previous setter */ .setBar2(...) (ne peut pas utiliser des retours à la ligne (dans un commentaire comme celui-ci 🙁 ... j'espère que vous obtenez le point considérant 10 de ces incubateurs ou plus complexes des appels)
- aussi, cela permet d'étape à travers le "train" avec un débogueur 😀
- "Facile à lire" dépend de la personne. C'est pourquoi nous avons tant de modèles différents 😉
InformationsquelleAutor cletus
82

Pour résumer:
- il a appelé à une "interface fluide", ou "méthode de chaînage".
- 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).
- Je 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 set* 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.
- btw, c'est "fluent", pas "fluide"...comme il permet de structurer une série d'appels de méthode comme une langue parlée.
- Le dernier point sur l'immuabilité est très important. L'exemple le plus simple est de la Chaîne. Java devs s'attendre à ce que lors de l'utilisation de méthodes sur la Chaîne qu'ils obtiennent totalement nouvelle instance et pas le même, mais a modifié instance. Avec une interface fluide, il devrait être mentionné dans la documentation de la méthode que l'objet retourné est " il " à la place de la nouvelle instance.
- CE doit être accepté, pas plus de réponses...
- Si je suis d'accord dans l'ensemble, je suis en désaccord que cela viole le "faire une seule chose" principal. De retour this n'est guère complexe de la science de fusée. 🙂
- point supplémentaire: il viole également la Commande de requête principe de séparation des pouvoirs.
InformationsquelleAutor ndp
75

Je préfère utiliser " par " des méthodes pour cela:
```
public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}
```
Ainsi:
```
list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));
```
- +1 Pour intéressant la convention. Je ne vais pas l'adopter dans mon propre code, car il semble être maintenant vous devez avoir un get, un set et un with pour chaque champ de la classe. C'est encore une solution intéressante, cependant. 🙂
- Cela dépend de combien de fois vous appelez des poseurs. J'ai trouvé que si ces setters appelé beaucoup de choses, il vaut la peine de les ajouter car il simplifie le code partout ailleurs. YMMV
- Et si vous l'avez ajoutée à Project Lombok's @Getter/@Setter annotations... ce serait fantastique pour le chaînage. Ou vous pouvez utiliser quelque chose comme le Kestrel combinator (github.com/raganwald/Katy) que JQuery et Javascript démons de l'utilisation.
- Je pense qu'il y a une erreur dans le code. withFoo(...) doit déclarer Employé comme valeur de retour - pas de Chaîne.
- Aussi, pouvez-vous indiquer certaines bibliothèques populaires à l'aide de ce modèle?
- Merci, j'ai corrigé le type de retour. Quant à votre question, sur le dessus de ma tête, je ne sais pas du tout bibliothèques populaires qui utilisent ce modèle.
- Que faire si le Java Bean est une Entité? "set", "get" préfixes ne peut pas être omis, car ils sont à la convention d'affectation de noms.
- D'accord. Merci de relire mon commentaire, ce que je préconise est d'inclure une méthode qui retourne l'auto de type, en plus des méthodes get et set.
- Cool l'idée de base. J'ai eu des problèmes avec GWT AutoBeans de la (dé)sérialisation avec les méthodes couramment ici et, essentiellement, de l'utilisation de vos idée dans l'avenir de cette façon (ce qui est plus aussi visuellement/pour l'autocomplétion, etc. - pour la méthode habituelle): void setFoo(Foo foo); Employee setFoo$(Foo foo) (le with ne semble pas être une meilleure idée pour le con arguments pour moi)
- En fait je viens de remarquer que le java.temps immuable classes en Java 8 utilisation de ce modèle, par exemple LocalDate.withMonth, withYear, etc.
- le with préfixe est une convention différente. comme @qualidafial a donné un exemple. méthodes avec le préfixe with ne doit pas renvoyer de this mais plutôt une nouvelle instance comme l'instance en cours, mais with ce changement. Ceci est fait pour lorsque vous souhaitez que vos objets soient immuables. Alors quand je vois une méthode avec le préfixe with je suppose que je vais avoir un nouvel objet, pas le même objet.
InformationsquelleAutor qualidafial
25

Si vous ne voulez pas rentrer 'this' de l'incubateur, mais ne voulez pas utiliser la deuxième option, vous pouvez utiliser la syntaxe suivante pour définir les propriétés:
```
list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});
```
Que d'un côté je pense que c'est légèrement plus propre en C#:
```
list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});
```
- double croisillon d'initialisation peuvent avoir des problèmes avec égal à égal, car il crée un anonyme intérieur de la classe; voir c2.com/cgi/wiki?DoubleBraceInitialization
- Clairement que le problème est la faute de la personne qui a gâché le equals méthode. Il y a très propres moyens de traiter avec les classes anonymes dans equals si vous savez ce que vous faites.
- C'est mon nouveau favori maintenant, merci! 🙂
- fonctionne uniquement pour les nouvelles objets si!
InformationsquelleAutor Luke Quinane
11

Non seulement les sauts de la convention de getters/setters, il rompt également le Java 8 méthode de cadre de référence. MyClass::setMyValue est un BiConsumer<MyClass,MyValue>, et myInstance::setMyValue est un Consumer<MyValue>. Si vous avez votre setter retour this, alors ce n'est plus une instance valide de Consumer<MyValue>, mais plutôt un Function<MyValue,MyClass>, et sera la cause de quelque chose en utilisant la méthode des références à ces setters (en supposant qu'ils sont des méthodes void) à la pause.
- Il serait génial si Java a d'une certaine façon à la surcharge par le type de retour, et pas seulement la JVM. Vous pourriez contourner un grand nombre de ces dernières modifications facilement.
- Vous pouvez toujours définir une interface fonctionnelle qui s'étend à la fois Consumer<A> et Function<A,B> en fournissant une implémentation par défaut de void accept(A a) { apply(a); }. Ensuite, il peut facilement être utilisé comme un et ne cassera pas le code qui exige une forme spécifique.
InformationsquelleAutor Steve K
7

Je ne sais pas Java, mais je l'ai fait en C++.
D'autres personnes l'ont dit, il rend les lignes à très long et très difficile à lire,
mais je l'ai fait comme ça des tas de fois:
```
list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));
```
C'est encore mieux:
```
list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));
```
au moins, je pense. Mais vous êtes les bienvenus à downvote moi et appelez-moi un terrible programmeur si vous le souhaitez. Et je ne sais pas si on peut même le faire en Java.
- Le "toujours mieux", ne se prêtent pas bien à la Source au Format de code fonctionnalités proposées par les IDE. Malheureusement.
- vous avez probablement raison... La seule auto-formateur, j'ai utilisé est emacs' auto indentation.
- Le code Source de formateurs peuvent être contraints par un simple // après chaque appel de méthode dans la chaîne. Il uglies de votre code un peu, mais pas autant que d'avoir votre vertical série de déclarations reformaté horizontalement.
- Vous n'avez pas besoin // après chaque méthode, si vous configurez votre IDE de ne pas se joindre à déjà des lignes (par exemple, Eclipse > Propriétés > Java > Code > Formateur > retour à la Ligne > ne Jamais joindre à déjà des lignes).
InformationsquelleAutor Carson Myers
6

Ce schéma (pun intended), appelé "fluent interface", est en train de devenir très populaire aujourd'hui. C'est acceptable, mais ce n'est pas vraiment ma tasse de thé.

InformationsquelleAutor Noon Silk
6

Car il n'a pas de retour void, il n'est plus valide JavaBean le setter de la propriété. Que peut-importe si vous êtes l'une des sept personnes dans le monde à l'aide de visual "Bean Builder" outils", ou de l'un des 17 à l'aide de JSP-bean-setProperty éléments.
- Il importe aussi si vous utilisez des haricots connaissance des frameworks comme Spring.
- ou si vous utilisez l'API d'introspection pour écrire réfléchissant code...
InformationsquelleAutor Ken
5

Au moins en théorie, il peut endommager l'optimisation des mécanismes de la machine par la mise en fausses dépendances entre les appels.

Il est censé être en sucre syntaxique, mais en fait, peut créer des effets secondaires chez les super-intelligent Java 43 de la machine virtuelle.

C'est pourquoi je vote pas, ne l'utilisez pas.
- Intéressant...pourriez-vous développer un peu?
- D'accord, j'aimerais en savoir plus sur la façon dont cela peut affecter l'optimisation
- Il suffit de penser comment superscalar processeurs traitent de l'exécution en parallèle. L'objet pour exécuter la deuxième set méthode dépend de la première set méthode bien qu'il soit connu par le programmeur.
- Je continue à ne pas suivre. Si vous définissez Foo et puis Bar avec deux états distincts, l'objet pour lequel vous êtes Barre de réglage a un état différent de celui de l'objet pour lequel vous êtes réglage de Foo. Ainsi, le compilateur ne pouvais pas paralléliser ces déclarations, soit. Au moins, je ne vois pas comment il pourrait sans introduire une hypothèse injustifiée.(Depuis je n'ai aucune idée à ce sujet, je ne vous cacherai pas que Java 43 n'ont, en fait, la parallélisation dans les cas mais pas dans l'autre et d'introduire l'hypothèse injustifiée dans un cas mais pas dans l'autre).
- Peut-être quelque chose comme ceci: obj.modifyList(aList).modifyList(anotherList), où modifyList ne modifie pas this, encore besoin de savoir ce que this est.
- Si vous ne connaissez pas, testez. -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining La java7 jdk certainement inlines enchaîné méthodes, et n'environ le même nombre d'itérations qu'il faut pour marquer nulle setters comme à chaud et en ligne aussi. Il me semble que vous sous-estimez la puissance de la JVM de l'opcode de l'élagage des algorithmes; s'il sait que vous êtes de retour cette, il va sauter le jrs (java instruction return) opcode et il suffit de laisser ce sur la pile.
- Mais il faut vraiment prendre en compte si l'optimisation est un problème pour son code. Presque tous les code que j'ai écrit dans ma carrière a été de ne pas être exécuté superfast ou quelque chose, mais devrait plutôt être compréhensible et sans défaut. Donc, je dirais que la majorité de code/codeurs n'ont pas besoin d'être extrêmement préoccupé par la vitesse plutôt que la facilité de maintenance qui comprend également la lisibilité. Java est un très bon exemple qu'il a été l'un des plus faibles lang. il y a quelques années, mais encore avait été adopté à la quasi partout, parce que la vitesse de aug. sur le dur et le logiciel.-côté de toute façon, mais la facilité de maintenance est beaucoup plus important.
- Andreas, je suis d'accord, mais les problèmes apparaissent quand vous avez la couche sur la couche de l'inefficacité de code. 99% du temps, vous devriez code pour plus de clarté qui est dit beaucoup de choses ici. Mais il y a aussi des moments où vous avez besoin d'être réaliste et de l'utilisation de vos années d'expérience prématurément de les optimiser en général sens architectural.
InformationsquelleAutor Marian
5

Ce n'est pas une mauvaise pratique à tous. Mais ce n'est pas compatiable avec JavaBeans Spec.

Et il y a beaucoup de cahier des charges dépend de ces accesseurs standards.

Vous pouvez toujours les faire co-exister les uns aux autres.
```
public class Some {
    public String getValue() { //JavaBeans
        return value;
    }
    public void setValue(final String value) { //JavaBeans
        this.value = value;
    }
    public String value() { //simple
        return getValue();
    }
    public Some value(final String value) { //fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}
```
Maintenant, nous pouvons les utiliser ensemble.
```
new Some().value("some").getValue();
```
Voici une autre version pour objet immuable.
```
public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}
```
Maintenant nous pouvons le faire.
```
new Some.Builder().value("value").build().getValue();
```
- Mon montage a été rejeté, mais votre Constructeur exemple n'est pas correct. Tout d'abord, .valeur() ne retourne rien, et il n'a même pas mis la some champ. Deuxièmement, vous devriez ajouter une clause de sauvegarde et de définir some à null dans le build() pour Some est vraiment immuable, sinon on pourrait appeler builder.value() sur la même instance de Générateur de nouveau. Et Enfin, oui, vous avez bien un constructeur, mais votre Some a encore un constructeur public, ce qui signifie que vous n'avez pas prôner ouvertement l'utilisation du Générateur, c'est à dire que l'utilisateur ne connait pas d'autres que par l'essai ou la recherche d'une méthode pour définir une coutume value à tous.
- si la réponse est incorrecte, vous devez écrire votre propre réponse, ne pas essayer et modifier de quelqu'un d'autre en forme
- Je devrais laisser une information fausse, il y quand il a juste besoin d'un peu de montage? Ce n'est pas "l'édition en forme", mais de corriger les petites erreurs qu'il a faite. Aussi, son Générateur exemple est une extension normale de réponse, et ne justifie pas un tout à fait propre réponse par moi-même.
- Je viens de mettre à jour ma réponse.
- Grand. Merci! Et désolé si je semble impoli avant.
- Sentez-vous svp libre pour tout commentaire supplémentaire pour les accessoires. Pour info, je ne suis pas celui qui a rejeté votre modifier. 🙂
- Je sais, je sais. ^^ Et merci pour la nouvelle version, qui offre un réel mutable "Immuable-Certains" builder. Et c'est une solution intelligente que mon montage tentatives qui, en comparaison, encombré le code.
InformationsquelleAutor Jin Kwon
3

Je suis en faveur de setters avoir "cette" les retours. Je n'ai pas de soins si ce n'est pas les haricots conforme. Pour moi, si c'est ok pour avoir le "=" expression/l'instruction, puis setters que les valeurs de retour est très bien.

InformationsquelleAutor Monty Hall
3

Paulo Abrantes propose une autre façon de faire JavaBean setters couramment: définir intérieure d'un constructeur de la classe pour chaque JavaBean. Si vous êtes en utilisant des outils qui se déconcerté par les setters que les valeurs de retour, Paulo modèle pourrait aider.
- J'avais upvote, mais votre lien est rompu.
- href="http://web.archive.org/web/20101018140949/http://www.pabrantes.net/blog/space/start/2007-11-14/1" >utiliser la wayback machine, Luc
InformationsquelleAutor Jim Ferrans
2

Je préfère cette approche, mais j'ai décidé contre elle.

Raisons:
- Des raisons de lisibilité. Elle rend le code plus lisible, chaque setFoo() sur une ligne distincte. Vous avez l'habitude de lire le code beaucoup, beaucoup plus de temps que le temps de vous écrire.
- Effet secondaire: setFoo() ne devraient définir le champ foo, rien d'autre. De retour c'est un supplément de "CE qui fut".
Le Générateur de modèle que j'ai vu ne pas utiliser le setFoo(foo).setBar(bar) de la convention, mais plus de foo(foo).bar(bar). Peut-être c'est précisément pour ces raisons.

C'est toujours une question de goût. J'aime juste les "moins de surprises" approche.
- Je suis d'accord sur le côté effet. Setters qui renvoient des choses qu'elle viole leur nom. Vous êtes réglage de foo, mais vous obtenez un objet? Est-ce un nouvel objet ou j'ai modifié le vieux?
InformationsquelleAutor Thorbjørn Ravn Andersen
2

Ce modèle particulier est appelé le Chaînage de Méthode. Lien wikipédia, ce qui a davantage d'explications et d'exemples de la façon dont c'est fait dans divers langages de programmation.

P. S: Juste la pensée de le laisser ici, depuis que je suis à la recherche pour le nom spécifique.

InformationsquelleAutor capt.swag

Si vous utilisez la même convention dans l'ensemble de l'application, il semble bien.

Sur le sous-main si la partie existante de votre application utilise la norme de la convention, je garderais d'elle et d'ajouter que les constructeurs plus compliqué classes

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

C'est exactement ce que le Générateur de modèle a été conçu pour corriger. Elle ne casse pas des lambdas de Java 8, il ne rompt pas capricieux JavaBeans outils, et elle ne cause pas de problèmes d'optimisation dans la JVM (puisque l'objet n'existe que lors de l'instanciation). Il résout également le "trop nombreux constructeurs" problème que vous obtenez tout simplement en n'utilisant les constructeurs, ainsi que l'élimination des tas de pollution de double-brace anonyme classes.

InformationsquelleAutor Marcin Szymczak

1

À première vue: "Horrible!".

Sur la poursuite de la réflexion
```
list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));
```
est en fait moins d'erreurs que
```
Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);
```
Donc tout à fait intéressant. L'ajout de l'idée à l'toolbag ...
- Non, c'est toujours horrible. À partir d'un point de vue de l'entretien, celle-ci est mieux parce que c'est plus facile à lire. En outre, de code automatisé pions comme CheckStyle va appliquer les lignes à 80 caractères par défaut, le code devrait obtenir enveloppé de toute façon, en aggravant la lisibilité/maintenance question. Enfin - et c'est de Java; il n'y a aucun avantage à l'écriture tout sur une seule ligne lorsque ça va être compilé en byte code, de toute façon.
- personnellement, je pense que le premier est plus facile à lire, surtout si vous êtes à la création de plusieurs objets de cette façon.
- Le Code d'une méthode. Écrire un exemplaire en format couramment; une autre copie dans l'autre. Maintenant donner les deux copies d'un couple de personnes, et demander à ce qu'ils trouvent cela plus facile à lire. Plus rapide à lire, plus rapide à coder.
- Comme la plupart des outils, il peut être facile d'en abuser. JQuery est orientée autour de cette technique et est donc sujette à appel long des chaînes que j'ai trouvé en fait altère la lisibilité.
- Il serait bien si il y avait des retours à la ligne (avant chaque point et en retrait. Puis, ce serait aussi lisible que la deuxième version. En fait plus, car il n'est pas redondant list au début.
InformationsquelleAutor djna
1

Oui, je pense que c'est une bonne Idée.

Si je pouvais ajouter quelque chose, ce à propos de ce problème :
```
class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}
```
Cela fonctionne :
```
new Friend().setNickName("Bart").setName("Barthelemy");
```
Ce ne sera pas acceptée par Eclipse ! :
```
new Friend().setName("Barthelemy").setNickName("Bart");
```
C'est parce que setName() renvoie un Peuple et non pas un Ami, et il n'y a pas de PeoplesetNickName.

Comment pourrions-nous écrire des organismes de normalisation pour le retour de l'AUTO de la classe au lieu du nom de la classe ?

Quelque chose comme ce serait bien (si le mot-clé SELF existerait). N'existent de toute façon ?
```
class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}
```
- Il y a quelques autres compilateurs Java outre Éclipse qui n'acceptent pas que :). Fondamentalement, vous êtes en cours d'exécution de la volaille de la Java le type de système (ce qui est statique, pas dynamique comme certains langages de script): vous aurez à jeter ce sort de setName() à un Ami avant de pouvoir setNickName() sur celui-ci. Donc, malheureusement, pour des hiérarchies d'héritage ceci élimine une grande partie de l'avantage de la lisibilité et le rend potentiellement utiles à la technique n'est pas si utile.
- L'utilisation des génériques. classe Chainable <Auto s'étend Chainable> { public doSomething(){return (Self)this;} } Il n'est pas techniquement type de coffre-fort (il se classe en fonte si vous implémentez la classe d'un type que vous ne peut pas être le cas), mais c'est la grammaire correcte, et les sous-classes sera de retour de leur propre type.
- En outre, Ce "SOI", que Baptiste est appelé auto type, n'est pas présent dans de nombreuses langues (Scala est vraiment le seul que je peux penser en ce moment), où l'Ajax de l'utilisation de médicaments Génériques est la soi-disant "Curieusement récurrents de modèle de modèle", qui tente de composer avec un manque de soi, mais il a quelques inconvénients: (à partir de class C<S extends C<S>>, ce qui est plus sûr qu'un simple S extends C. a) Si A extends B, et B extends C<B>, et vous avez Un, vous ne savez que B est renvoyé à moins qu'Un des remplacements de chaque méthode. b) Vous ne pouvez pas désigner un local, non-raw C<C<C<C<C<...>>>>>.
InformationsquelleAutor Baptiste
1

En général c'est une bonne pratique, mais vous pourriez avoir besoin pour le type de fonctions de type Booléen pour déterminer si l'opération a réussi ou pas, c'est un de trop. En général, il n'y a pas de dogme à dire que c'est une bonne ou lit, il s'agit de la situation, bien sûr.
- Comment au sujet de l'utilisation d'exceptions pour indiquer une condition d'erreur? Codes d'erreur peut être facilement ignorés comme beaucoup de programmeurs C douloureusement ont appris. Des Exceptions peuvent bulle de la pile à l'endroit où ils peuvent être manipulés.
- Les Exceptions sont préférables, mais les codes d'erreur sont également utiles lorsque vous ne pouvez pas utiliser les exceptions.
- Salut @Narek, pourriez-vous préciser dans quels cas il est préférable d'utiliser des codes d'erreur dans les setters, plutôt que des exceptions, et pourquoi?
InformationsquelleAutor Narek
0

De la déclaration
```
list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));
```
je vois deux choses

1) déclaration vide de Sens.
2) le Manque de lisibilité.

InformationsquelleAutor Madhu

Cela peut être moins lisible

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

ou ce

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

C'est beaucoup plus lisible que:

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

Je pense que c'est assez lisible si vous n'essayez pas de mettre tout votre code sur une seule ligne.

InformationsquelleAutor Scott

0

J'ai fait mes setters pour un bon moment et le seul vrai problème est avec les bibliothèques qui collent avec le strict getPropertyDescriptors pour obtenir le haricot lecteur/enregistreur de haricot accesseurs. Dans ces cas, votre java "haricot" n'aura pas les writters que vous attendez.

Par exemple, je ne l'ai pas testé, mais je ne serais pas surpris que Jackson ne reconnaît ceux que les setters lors de la création vous des objets java à partir de json/maps. J'espère que je me trompe sur ce point (je vais la tester au plus vite).

En fait, je suis en train d'élaborer un léger SQL centrée sur l'ORM et j'ai ajouter un peu de code au-delà de getPropertyDescriptors reconnus setters qui revient cette.

InformationsquelleAutor Jeremy Chone
0

Il y a longtemps à répondre, mais mes deux cents ... Sa belle. Je souhaite à cette interface fluide ont été utilisés le plus souvent.

Répétition de la 'usine' variable de ne pas ajouter plus d'info ci-dessous:
```
ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...
```
C'est plus propre, à mon humble avis:
```
ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...
```
Bien sûr, comme l'une des réponses déjà mentionné, l'API Java faudrait être tordu pour le faire correctement pour certaines situations, comme l'héritage et des outils.

InformationsquelleAutor Josef.B
0

Il est préférable d'utiliser d'autres constructions de langage, si disponible. Par exemple, dans Kotlin, vous pouvez utiliser avec, appliquer, ou laisser. Si l'utilisation de cette approche, vous n'aurez pas vraiment besoin de retourner une instance de votre setter.

Cette approche permet à votre code client:
- Indifférent au type de retour
- Plus facile à maintenir
- Éviter compilateur effets secondaires
Voici quelques exemples.
```
val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}
```
InformationsquelleAutor Steven Spungin
0

Si je suis en train d'écrire une API, je vais utiliser le retour de cette" définition des valeurs qui ne sera définie qu'une seule fois. Si j'ai d'autres valeurs que l'utilisateur doit être en mesure de changer, j'utilise une norme nulle setter à la place.

Cependant, c'est vraiment une question de préférence et en enchaînant les poseurs n'a pas l'air tout à fait cool, à mon avis.

InformationsquelleAutor Kaiser Keister
0

Je suis d'accord avec toutes les affiches affirmant cela rompt avec le JavaBeans spec. Il y a des raisons à préserver, mais j'ai aussi l'impression que l'utilisation de ce Générateur de Modèle (qui a été évoqué) a sa place; tant qu'il n'est pas utilisé partout, il devrait être acceptable. "Il la Place", pour moi, est le point final est un appel à un "build()" la méthode.

Il existe d'autres moyens de réglage de toutes ces choses, bien sûr, mais l'avantage ici est qu'il évite 1) de nombreux paramètres les constructeurs publics et 2) partiellement les objets spécifiés. Ici, vous avez le générateur de recueillir ce qu'il faut, et puis d'appeler sa "build()" à la fin, qui peut ensuite s'assurer que partiellement objet spécifié n'est pas construit, étant donné que l'opération peut être donné moins de visibilité publique. L'alternative serait de paramètre "objets", mais qui à mon humble avis pousse juste le problème d'un niveau.

Je n'aime pas beaucoup-paramètre constructeurs parce qu'il est plus probable que beaucoup de le même type d'arguments sont passés dans l', ce qui peut rendre plus facile à passer le mauvais arguments pour les paramètres. Je n'aime pas en utilisant beaucoup de setters parce que l'objet pourrait être utilisée avant d'être entièrement configuré. De plus, la notion d'ayant des valeurs par défaut basé sur des choix précédents est mieux servi avec un "build()" la méthode.

En bref, je pense que c'est une bonne pratique, si elle est utilisée correctement.

InformationsquelleAutor Javaneer
-4

Mauvaise habitude:
un setter ensemble
un getter obtenir

qu'en déclarant explicitement une méthode, qui le fait pour U
```
setPropertyFromParams(array $hashParamList) { ... }
```
- pas bon pour l'auto-complétion et de refactoring et de la lisibilité de l'anb code réutilisable
- Parce que: 1) vous devez Vous rappeler à l'ordre ou lire à partir de docs, 2) vous perdez tous type de compilation de sécurité, 3) vous devez lancer les valeurs (ce et 2) est un non-problème dans un langage dynamique, bien sûr), 4), vous pouvez pas étendre cette utilement autres que la vérification de la matrice de longueur sur chaque invocation, et 5) si vous changer quoi que ce soit, l'être de l'ordre ou même de l'existence de certaines valeurs, vous pouvez pas vérifiez que ni runtime ni compiler moment sans même avoir de doute tous. Avec les setters: 1), 2), 3): Pas un problème. 4) Ajouter de nouvelles méthodes ne rien casser. 5) message d'erreur explicite.
InformationsquelleAutor Ulrich Tevi Horus

Vous devez vous connecter pour publier un commentaire.