6
votes

Y a-t-il des avantages pour utiliser Getters / Setters dans une classe pour ses propres champs?

Habituellement, dans mes propres projets, j'utilise des getters et des setters pour tout accès sur le terrain et j'ai suivi pour faire la même chose sur mon travail. Il y a quelque temps, le chef de technologie de notre projet m'a demandé pourquoi je faisais cela et pourquoi cela est-il meilleur que de simplement utiliser des champs eux-mêmes (avec une option de les déclarer protégé si elles devaient être accessibles par sous-classes). Je ne pouvais pas trouver une réponse claire.

Ainsi, y a-t-il des raisons d'utiliser des getters and Setters dans une classe pour leurs propres champs, ou est-il préférable d'utiliser des champs directement?


3 commentaires

Vous voulez dire que vous utilisez des getters privés et des setters dans votre classe?


Oui, dans les cas où le champ est profondément interne (mais ils sont rares). Sinon, protégé ou public.


Oh, privé getters et setters? J'ai mal interprété la question ... ignorer ma réponse alors.


6 Réponses :


1
votes

Vous voulez les déclarer comme getters et setters publics, ainsi que des champs privés. Cela signifie des classes externes (non sous-classes) qui souhaitent modifier les variables le font tous à travers les configurateurs et les obtenir via les getters. L'avantage de ceci est que si vous souhaitez contrôler comment ou quelle condition ils les obtiennent ou les définir ou souhaitent ajouter des informations, voire de débogage d'impression, cela signifie que vous devez seulement la mettre dans les getters et les configurateurs.

Il y a une très bonne explication des avantages sur Stackoverflow en fait:

en Java, différence entre défaut, public, protégé et privé

Bien sûr, ne faites que faire des méthodes lorsqu'elles sont réellement nécessaires, de la même manière, uniquement publiques si nécessaire par des classes externes.

espère que cela aide la défense!


0 commentaires

6
votes

La réponse la plus évidente est Effets secondaires: xxx

Si vous avez besoin du coût, utilisez getcost () . Si vous souhaitez voir si le coût a été calculé, utilisez coût .


2 commentaires

À peu près la seule raison d'utiliser des accesseurs privés que je pouvais aussi penser. Bien que je ne fais toujours que cela lorsque je dois en réalité, la grande majorité des champs privés et de forfaits devraient simplement être consultés directement. C'est dommage que Java ait ce champ / la séparation de la méthode pour l'accès à la propriété, pas besoin de cela.


Ce modèle s'appelle un heisenbug et considéré comme une mauvaise pratique.



0
votes

Cela fait partie de la question générale de la raison pour laquelle vous utilisez des getters et des setters. De nombreux développeurs les utilisent sans cependant, comme une question de pratique. Personnellement, je mets uniquement dans des getters / setters si j'en ai besoin.

Je vous suggérerais de faire ce qui est le plus clair / le plus simple à vous.

En général, si je peux facilement ajouter un getter / setter plus tard, j'en ai besoin, je ne l'ajouterai pas. S'il serait difficile d'ajouter plus tard (ou si vous avez une utilisation immédiate pour eux), je les inclure.


0 commentaires

3
votes

S'il y a une logique commerciale autour de ces valeurs (ou il y a le potentiel de cette logique), il y a un avantage pour utiliser des getters et des setters, même pour des appels internes.

Par exemple, votre réglage peut effectuer une validation sur ses entrées et lancer une exception plutôt que de stocker une valeur non valide. Avoir tout votre code, utilisez ce réglage plutôt que de simplement définir des valeurs signifie directement que l'erreur est prise au moment où elle est effectuée plutôt que longtemps plus tard, lorsque cette valeur est utilisée. Un cas similaire pour un getter est quand il y a une valeur par défaut logique, qui doit être utilisée en cas de null. En utilisant un getter, vous pouvez écrire des méthodes locales sans avoir besoin de vérifications nulles continues ou d'options par défaut.

Cela dit, s'il n'y a pas de logique commerciale dans ces méthodes et qu'aucun effet secondaire causé par eux, il s'agit principalement d'une chose stylistique. Il est essentiellement la responsabilité de la classe d'être cohérente en interne, et aussi longtemps qu'il en reste, il est donc préférable de préférence personnelle / professionnelle, que vous accédez directement aux variables directement ou via des méthodes d'emballage.


0 commentaires

0
votes

Certains d'entre nous sont des développeurs Web, nous avons également recours à la création de JavaBeans et JavaBeans A son propre Spécification . Dans la spécification, il indique clairement:

  • La classe doit avoir un constructeur par défaut public (no-argument).
  • Les propriétés de la classe doivent être accessibles à utiliser obtenir , définir , est (utilisé pour les propriétés booléennes au lieu de obtenir) et d'autres méthodes.
  • La classe doit être sérialisable.

    La raison étant, JavaBeans a été conçue pour réutilisabilité où JavaBeans pouvait voyager dans toutes les technologies Java (E.G. Servlets, JSPS, RMI, Services Web, etc.).

    C'est ma valeur de 2centative sur la raison pour laquelle nous avons des getters / setters. Je crée principalement des JavaBeans.


0 commentaires

0
votes

Certaines personnes pensent qu'ils doivent toujours encapsuler tous les champs en utilisant des setters / getters. D'autres pensent que cette pratique ne doit pas être utilisée du tout.

Si votre classe n'a pas de logique pour les champs et est simplement utilisée comme titulaire, vous pouvez passer à l'aide de méthodes et déclarer vos champs comme public. Ce concept s'appelle également un objet de transfert de données (ou messager.) Mais en règle générale, vous devez utiliser l'attribut final de ces champs pour rendre votre classe immuable: xxx

Cependant, vous devez / ou il est fortement recommandé d'utiliser des setters / getters:

  • Dans les applications Web, il existe parfois des exigences pour utiliser des setters / getters. Voir les objets pojo / javabean.
  • Si votre classe va être utilisée dans un environnement simultané. Voir la concurrence Java dans la pratique, section 3.2: "Si un autre fil fait effectivement quelque chose avec une référence publiée n'a pas d'importance, car le risque d'utilisation abusive est toujours présent. [7] Une fois qu'un objet s'échappe, vous devez supposer qu'une autre classe ou fil peut malicieusement ou négligemment, abusif C'est une raison convaincante d'utiliser l'encapsulation: il est pratique d'analyser les programmes d'exactitude et de violation des contraintes de conception accidentellement "
  • Si vous souhaitez ajouter une logique supplémentaire lorsque vous définissez / obtenez des valeurs, vous devez utiliser des setters / getters. Il suffit de lire sur l'encapsulation et ses avantages.

    Ma propre opinion déclara toujours des champs comme "finale privée" et que ce n'est qu'alors, si nécessaire, modifiez ces propriétés.


0 commentaires