Quel est un bon cas d'utilisation des Beans Java?
Je viens de voir la spécification Java Beans. J'ai senti que l'utilisation uniquement de getters, setters et constructeur vide rendra le code plus trépidant et que le développeur doit gérer la piste pour définir correctement toutes les instances requises.
Quelqu'un pourrait-il me montrer un bon cas d'utilisation pour utiliser une telle conception? Je n'arrive pas à obtenir un sens. Il y a une utilisation à laquelle je peux penser - "Lorsque vous devez créer une instance d'une classe telle que ses membres de données seront décidés plus tard dans le code."
EDIT: Les gars que je suis ne pas initier une discussion. Vous ne voulez pas discuter des avantages / inconvénients. Je ne cherche pas de bibliothèques actuelles comme spring, etc., ce qui rend obligatoire l'utilisation de Beans. Je cherche un exemple pour comprendre les avantages d'ingénierie que les beans Java apporteraient. "Juste un exemple où la conception de Beans Java aiderait"
6 answers
Un certain nombre de bibliothèques et de spécifications (par exemple JPA, JavaEL) utilisent la spécification Java Beans et s'appuient exactement sur ce comportement.
L'utilisation de getters et setters a l'avantage de vous permettre d'ajouter du code à l'intérieur de ces méthodes, par exemple pour créer des propriétés "virtuelles" qui sont calculées à l'exécution plutôt que stockées dans un champ.
En outre, l'utilisation de getters et setters permet à d'autres frameworks d'envelopper ces méthodes et de fournir des fonctionnalités supplémentaires telles que la journalisation des modifications, etc. Dans de nombreux cas cela se fait en créant en interne une sous-classe et en remplaçant les getters et setters. L'utilisateur ne remarquerait pas cela puisque ce " tissage "ou" proxying " est souvent fait au moment de l'exécution. Hibernate, par exemple, l'utilise pour fournir une fonctionnalité de chargement paresseux lorsque vous appelez un getter pour accéder à une collection ou une entité associée.
Mise à Jour:
Selon la demande d'un exemple pour les propriétés "virtuelles":
Supposons que vous ayez un bean Person qui a les champs firstName et lastName. Vous pourrait ajouter une propriété virtuelle en lecture seule {[4] } en fournissant le getter suivant:
public String getName() {
return getFirstName() + " " + getLastName();
}
Mise à Jour 2:
Une autre note sur la raison pour laquelle les getters et les setters sont nécessaires: cela vient essentiellement du fonctionnement de Java. Les langages qui prennent directement en charge les propriétés, comme C#, vous permettraient d'écrire du code comme person.firstName = "Joe"; et d'utiliser toujours un setter s'il y en a un ou de générer une erreur si la propriété est en lecture seule. Donc, si vous ajoutez un setter pour firstName ces langues traduiraient en interne firstName = "Joe" en setFirstName("Joe") sans que le développeur ait à changer quoi que ce soit - une solution tout à fait élégante. :)
Puisque Java ne prend pas en charge cela, nous devons toujours fournir des méthodes d'accesseur (setters/getters) même si elles ne font rien de spécial - juste au cas où ellespourraient avoir besoin d'être modifiées à l'avenir.
Un constructeur vide est nécessaire pour créer une nouvelle instance via la réflexion de votre framework de persistance. Si vous ne fournissez aucun constructeur supplémentaire avec des arguments pour la classe, vous n'avez pas besoin de fournir un constructeur vide car vous en obtenez un par défaut.
D'après mon expérience, c'est pour éviter la situation où quelqu'un ajoute un constructeur avec des paramètres, et supprime ainsi efficacement le constructeur par défaut. En implémentant explicitement le constructeur par défaut c'est plus peu probable que cela arrive.
Aussi, je suppose que vous imaginez une classe avec beaucoup d'attibutes qui sera difficile à remplir uniquement avec des getters et des setters, mais notez également ces points:
- Getters automatisera la partie vue.
- Setters vous permettra d'ajouter une validation ou un contrôle d'erreur si nécessaire.
Getters & setters assure the basic object oriented concept - Encapsulation
Imaginez que vous avez écrit le code pour une classe et une autre douzaine de programmeurs de votre entreprise tous les programmes écrits qui ont utilisé votre classe. Si , tout le monde peut changer votre variable d'instance et cela peut nuire à votre code .
Donc vous devriez
Keep instance variables protected (avec un access modifier, often private).
Make public accessor methods, et forcer le code appelant à utiliser ces méthodes
rather than directly accessing the instance variable.
Leur code a fait apparaître des erreurs dans votre code.
Regardez l'exemple suivant
public class MyClass{
public int size;
public int weight;
...
}
public class OthersClass {
public static void main (String [] args) {
MyClass myClass= new MyClass();
myClass.size = -5; // Legal but bad logic
}
}
Au-delà des avantages et des inconvénients réels de la spécification JavaBeans, je pense qu'il est important de se rappeler qu'il s'agit d'une spécification introduite en 1996 pour permettre l'édition visuelle du code Java.
Je ne sais pas si cette approche de la programmation a réussi et a été adoptée (je ne l'ai jamais utilisée, personnellement). Ce que je sais, c'est que la spécification a continué à vivre et à être appliquée très largement (À mon humble avis parfois aussi dans des contextes dans lesquels n'était pas le plus approprié).
Je pense que le l'endroit le plus utile dans lequel JavaBeans peut être utilisé est un framework. Un bon exemple est le printemps. Une classe JavaBean est très appropriée chaque fois que l'instanciation de classe n'est pas responsable du programmeur, mais est déléguée au conteneur d'application (par exemple via la réflexion).
JavaBeans, comme vous l'avez décrit ci-dessus, peut être utilisé comme DAO (Objets d'accès aux données) pour récupérer et enregistrer des données dans une base de données (SQL principalement). Ils sont utiles où tout ce qui vous intéresse vraiment, ce sont les données
Beaucoup de gens vous diront que les Beans Java sont tellement meilleurs que d'utiliser des objets Java simples qui agissent comme des "objets de transfert de données".
, Mais d'autres personnes, par exemple ce gars ici dans son livre célèbre https://cleansourcecode.files.wordpress.com/2013/10/clean-code.pdf suggère que le plus souvent, les "beans" et les getters et setters n'ont pas beaucoup de valeur supplémentaire (tout le chapitre 6 est consacré à cette question).
Donc vous devriez décider par vous-même (et probablement avec vos coéquipiers) si votre problème est mieux résolu avec des " Beans Java "ou des"objets de transfert de données simples".
Bien sûr ,les "beans" vous obligent à utiliser des setters, qui vous permettent d'ajouter ultérieurement une validation. D'autre part: un tel changement modifie la sémantique de vos méthodes; et il peut être tout à fait faux que tout à coup un setter fasse la validation et commence à lancer des exceptions. Parce que, si vous modifiez le contrat de vos méthodes; vous ne pourriez pas vouloir faire cela implicitement sous les couvertures.