Comment la conception de JavaBeans s'accorde-t-elle avec la dissimulation d'informations?

Question

Il y a deux semestres, j'ai eu un professeur qui a dit:

Certains d'entre vous ont été dit toujours inclure des méthodes setter et getter pour toutes les variables d'instance privées. Je dis que cela casse l'information cachée, et aboutit souvent à des systèmes où les invariants ne peuvent pas être appliqués.

Maintenant, cela me semble juste. Mais ne pas inclure ces types de setters/getters une partie essentielle de la création de JavaBeans? Si oui, pourquoi? Si ce n'est pas le cas, que puis-je mal comprendre à propos de JavaBeans?

Answer 1

Les getters et les setters ne sont pas requis dans une classe Java Bean. Tout ce qui est requis est que la classe doit être publique, elle doit avoir un constructeur public sans argument et doit implémenter Serializable. Cependant, pour que les variables soient détectées automatiquement lorsque votre bean est utilisé, vous devez fournir des getters et setters suivant une convention de nommage standard (getVarname, setVarname ...).

Dans tous les cas, vous ne voulez rendre visibles à l'extérieur que les variables qui voient une entreprise en dehors de votre classe.

Answer 2

C'est généralement assez simple, vous exposer des setters/getters pour les variables que vous devez rendre visibles à l'extérieur, et vous n'exposez pas les setters/getters à des variables que personne d'autre ne connaît.

Answer 3

Votre professeur a raison. Vous ne voulez pas créer aveuglément des getters et setters pour toutes les variables d'instance. Vous voulez les créer là où ils sont requis.

Si vous avez une classe BankAccount avec une variable d'instance balance, la création de getters et setters est logique si vous voulez pouvoir vérifier et régler la balance.

Même ici, il y a des informations qui se cachent - sous la forme d'encapsuler l'implémentation. Le getter "double getBalance()" peut simplement renvoyer la valeur de la variable d'instance sous-jacente s'il s'agit d'un double, ou renvoyer une valeur dérivée d'un BigDecimal s'il s'agit du choix d'implémentation de la variable ou s'il peut appeler un site Web distant service et renvoyer le résultat. Ainsi, le getter/setter permet toujours à l'implémentation de varier et donc ne viole pas l'encapsulation (et par extension, ni JavaBeans). Ce que JavaBeans fait pour vous est de définir une interface (getXXX(), setXXX()) pour obtenir et définir des "propriétés", attributs d'une classe que les utilisateurs voudraient typiquement examiner ou modifier. Si votre classe a des informations qui ne sont pas considérées comme une "propriété", il n'est pas nécessaire de les exposer. Par exemple, supposons que la classe BankAccount possède une variable d'instance utilisée pour valider les retraits. Si le client n'a pas besoin d'accéder ou de modifier cela, il ne sert à rien de créer un getter ou un setter pour cela.

Answer 4

Vous pouvez lire Why getter and setter methods are evil:

Vous pourriez objecter en disant: "Mais qu'est-ce à propos JavaBeans?" Et eux? Vous pouvez certainement construire JavaBeans sans getters et setters. Les classes BeanCustomizer, BeanInfo et BeanDescriptor existent toutes pour exactement dans ce but.Les JavaBean concepteurs de spécifications ont jeté le getter/setter idiome dans l'image parce qu'ils pensaient que ce serait un moyen facile de faire rapidement un quelque chose de haricots, vous pouvez faire pendant que vous apprenez comment faire droit. Malheureusement, personne n'a fait ça.

accesseurs ont été créés uniquement comme un moyen pour marquer certaines propriétés si un programme constructeur de l'interface utilisateur ou équivalent pourrait les identifier. Vous n'êtes pas censé appeler ces méthodes vous-même. Il existe pour un outil automatisé à utiliser. Cet outil utilise les API d'introspection dans la classe Class pour trouver les méthodes et d'extrapoler l'existence de certaines propriétés de la méthode noms. En pratique, cet idiome basé sur l'introspection n'a pas été mis au point par . Il a rendu le code beaucoup trop compliqué et procédural. Les programmeurs qui ne comprennent pas les données appellent effectivement les accesseurs , et par conséquent, le code est moins maintenable.