Oui, hibernate joue avec la visibilite des methodes pour pouvoir acceder a des getter/setter private/protected, idem pour les constructeurs sans argument protected. C'est techniquement qq chose d'assez trivial a faire, c'est juste lourd a mettre en place, l'api d'instrospection Java n'etant pas des plus agreable a utiliser.
Et oui, ca va plus ou moins a l'encontre de l'encapsulation, mais pas vraiment en fait. On va dire que c'est un moindre mal en fait vu ce qu'hibernate apporte.
Faut pas voir hibernate comme une couche au meme niveau que tes objets ou comme un consommateur de tes objets, mais une couche qui se met en dessous, entre tes objets et ta DB.
C'est donc ok d'acceder au contenu de l'objet en outrepassant les regles de l'objet dans ce cas. Faut juste garder a l'esprit comment hibernate marche pour eviter certains pieges.
Ca tord donc un peu le concept objet ou l'objet est maitre chez lui, mais vu ce que ca t'apporte quand t'as de gros graphes d'objets et une DB assez touffue, ben c'est vraiment un moindre mal.
Sinon, ce qui justifie que ces methodes soient privees, c'est assez simple en fait.
Au niveau objet, ton attribut est prive pour les raisons usuelles: aucune raison de l'exposer, il est modifie par des methodes publique plus haut niveau.
Typiquement, une collection tu ne veux pas que tes consommateur puisse la modifier directement, mais passent par des methodes add/remove, tu vas avoir:
private List maCollection = new ArrayList();
public void addMachin(machin)
{
du code de synchro ou des sanity tests
maCollection.add(machin)
encore du code
}
public void removeMachin(machin)
{
comme plus haut
}
Maintenant, tu veux que ta collection soit persistee dans la DB.
Hibernate se basant sur les getters/setters pour trouver les attributs a persister (je sais il peut le faire sur les attributs aussi, mais c'est assez vilain a regarder et dur a lire), la notion habituelle de java bean, ben tu vas creer un getter setter pour cet attribut.
Mais comme t'as aucune envie que qq1 ait un acces direct a ta collection, ben tu vas les mettre prives.
Le meme cas de figure peut aussi se presenter avec des methodes protected (accessible au package donc). Mais comme hibernate n'est pas du tout du meme package, ben il va devoir trifouiller la visibilite.
[^] # Re: Le compilateur ne fait pas ça ?
Posté par thedude . En réponse au journal Des outils d'audit de code Java. Évalué à 2.
Et oui, ca va plus ou moins a l'encontre de l'encapsulation, mais pas vraiment en fait. On va dire que c'est un moindre mal en fait vu ce qu'hibernate apporte.
Faut pas voir hibernate comme une couche au meme niveau que tes objets ou comme un consommateur de tes objets, mais une couche qui se met en dessous, entre tes objets et ta DB.
C'est donc ok d'acceder au contenu de l'objet en outrepassant les regles de l'objet dans ce cas. Faut juste garder a l'esprit comment hibernate marche pour eviter certains pieges.
Ca tord donc un peu le concept objet ou l'objet est maitre chez lui, mais vu ce que ca t'apporte quand t'as de gros graphes d'objets et une DB assez touffue, ben c'est vraiment un moindre mal.
Sinon, ce qui justifie que ces methodes soient privees, c'est assez simple en fait.
Au niveau objet, ton attribut est prive pour les raisons usuelles: aucune raison de l'exposer, il est modifie par des methodes publique plus haut niveau.
Typiquement, une collection tu ne veux pas que tes consommateur puisse la modifier directement, mais passent par des methodes add/remove, tu vas avoir:
private List maCollection = new ArrayList();
public void addMachin(machin)
{
du code de synchro ou des sanity tests
maCollection.add(machin)
encore du code
}
public void removeMachin(machin)
{
comme plus haut
}
Maintenant, tu veux que ta collection soit persistee dans la DB.
Hibernate se basant sur les getters/setters pour trouver les attributs a persister (je sais il peut le faire sur les attributs aussi, mais c'est assez vilain a regarder et dur a lire), la notion habituelle de java bean, ben tu vas creer un getter setter pour cet attribut.
Mais comme t'as aucune envie que qq1 ait un acces direct a ta collection, ben tu vas les mettre prives.
Le meme cas de figure peut aussi se presenter avec des methodes protected (accessible au package donc). Mais comme hibernate n'est pas du tout du meme package, ben il va devoir trifouiller la visibilite.