Conventions de dénomination des méthodes Java: Trop de getters

Question

Pourquoi Java noms de méthode utiliser le "get" préfixe de façon extensive? Au moins dans mes programmes Java il y a beaucoup de méthodes dont le nom commence par le mot "obtenir". Le pourcentage de méthodes est étrangement élevé. Je commence à penser que le mot "get" est en train de perdre son sens à cause de l'inflation. C'est le bruit de mon code.

J'ai remarqué qu'il y a une autre convention de nommage utilisée fonctionnelle/programmation déclarative et PL/SQL. Le nom de la méthode indique simplement que le retour de la méthode. Au lieu de account.getAmount() ou Time.getIsoFormattedDateString(Date date) ils utiliseront account.amount() et Time.isoFormattedDateString(Date date). Cela fait beaucoup de sens pour moi, que le nom de la fonction qui décrit le résultat de l'évaluation de la méthode (s'il n'y a pas d'effets secondaires, qui ne doit pas l'être de toute façon). Le "get" préfixe semble superflu.

Je viens de commencer la lecture du livre "Code Propre". Il est dit que les méthodes doivent faire une seule chose et que cette chose doit normalement être l'un des suivants:

1. Informer un objet sur un événement, généralement de passer l'évènement en tant que paramètre.
2. Poser une question à propos d'un objet, généralement avec le nom de la méthode formant un énoncé en langage naturel, en passant de l'objet en tant que paramètre et retournant une valeur de type boolean.
3. Chercher quelque chose, probablement passer un peu de recherche clés, ou d'un objet à être converties en tant que paramètre et retournant toujours l'objet désiré/valeur.

Ma question est à propos de la troisième catégorie. Existe-il des conventions de nommage, d'autres que "get" pour ce genre de méthodes? Quels critères utilisez-vous lors du choix des noms de méthode/préfixes?

Voici un exemple:

J'ai une classe avec deux méthodes d' getDates() et getSpecialDates(). getDates() retourne simplement la valeur d'une variable privée (la référence à une collection de dates). C'est un getter, ce que je comprends. getSpecialDates() "est différent; il appelle getDates(), extrait d'un filtre d'une autre classe, applique le filtre et renvoie de ce qui est effectivement un sous-ensemble de l' getDates().

La méthode getSpecialDates() pourrait être nommé computeSpecialDates(), findSpecialDates(), selectSpecialDates() ou elicitSpecialDates() ou quoi que ce soit. Ou je pourrais simplement le nom de il specialDates(). Et puis, pour des raisons de cohérence, je pourrais renommer getDates() en dates().

Pourquoi la peine de la séparation entre les méthodes qui doivent être préfixées par "get" et des méthodes qui ne doivent pas, et pourquoi s'embêter à trouver des mots de substitution pour "obtenir"?

Answer 1

Personnellement, je n'utilisez pas les getters et les setters chaque fois que c'est possible (ce qui signifie : je ne l'utilise pas tous les cadres qui en ont besoin, comme les jambes de suspension par exemple).

Je préfère écrire immuable objets (public final champs) lorsque cela est possible, sinon je viens d'utiliser des champs publics : moins de chaudière plaque de code, plus de productivité, moins d'effets secondaires. La justification initiale pour obtenir/définir l'est de l'encapsulation (vos objets aussi timide que possible), mais en fait, je n'ai pas besoin très souvent.

Dans Efficace Java, Joshua Bloch rend cet irrésistible recommandation :

Les Classes doivent être immuable, à moins que il y a une très bonne raison de le faire leur mutable... Si une classe ne peut pas être fait immuable, de limiter sa mutabilité autant que possible.

Dans le même livre, il dit aussi (mais je ne veux pas de copier l'ensemble du livre ici) :

Le modèle JavaBeans a de graves les inconvénients.

Je suis totalement d'aggre avec qui, depuis JavaBeans étaient à l'origine destinés à une très étroite du domaine du problème : la manipulation des composants graphiques dans un IDE. C'est une mauvaise pratique d'utiliser une solution conçue pour résoudre un autre problème.

Answer 2

Il provient des conventions de nommage JavaBeans .

Answer 3

La raison pour laquelle il y a tant de méthodes get * est en partie due au fait que Java ne prend pas en charge les "propriétés" comme les beans .net / COM et Java, et ces fonctions utilisent getX et setX pour répliquer les fonctionnalités d'une propriété appelée X. Certains IDE pour Java en profite pour permettre la définition et la récupération des propriétés.

Answer 4

L'une des raisons que les méthodes getter et setter sont souvent écrites en Java, en raison de l'utilisation de JavaBeans conventions.

La norme API Java n'est pas conforme lui-même à ce sujet, cependant. Par exemple, la classe String a length() méthode et de l'interface Collection définit une size() méthode, au lieu de getLength() ou getSize().

Java ne supporte pas l' uniforme principe d'accessibilité, de sorte que vous avez à écrire les méthodes getter et setter pour accéder à des propriétés.

Answer 5

L'une des raisons est que c'est une partie essentielle de la spécification Java Bean .