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. P>
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? P>
6 Réponses :
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. p>
Il y a une très bonne explication des avantages sur Stackoverflow en fait: P>
en Java, différence entre défaut, public, protégé et privé p>
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. P>
espère que cela aide la défense! p>
La réponse la plus évidente est Effets secondaires: Si vous avez besoin du coût, utilisez getcost () code>. Si vous souhaitez voir si le coût a été calculé, utilisez coût code>. P> p>
À 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.
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. P>
Je vous suggérerais de faire ce qui est le plus clair / le plus simple à vous. p>
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. P>
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. P>
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. P>
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. P>
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: P>
La raison étant, JavaBeans a été conçue pour C'est ma valeur de 2centative sur la raison pour laquelle nous avons des getters / setters. Je crée principalement des JavaBeans. P>
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: p> Cependant, vous devez / ou il est fortement recommandé d'utiliser des setters / getters: p> 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. P> P>
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é b> getters et setters? J'ai mal interprété la question ... ignorer ma réponse alors.