Sur le blog Chaotic Java on peut trouver une réflexion intéressante sur comment gérer l’accès aux collections d’une classe.
Deux méthodes sont proposées, la première est l’approche “paranoïaque” dans laquelle on ne met pas à disposition les collections utilisées par la classe. On propose juste des méthodes comme add/remove/get avec une gestion des erreurs pour avoir la main sur l’utilisation de la collection.
La deuxième méthode appelée approche “en toute confiance” (Trusting approach) est la méthode classique et naïve qui consiste à utiliser les getters/setters pour accéder aux collections de la classe. En laissant un accès total aux développeurs, on leur permet de faire tout et n’importe quoi.
L’article se termine par un récapitulatif (Pour & Contre) que je vous traduis :
Personnellement, j’utilise généralement la méthode “en toute confiance”, on peut ajouter des commentaires Javadoc pour préciser un comportement particulier ou des prérequis d’utilisation.
Personnellement, j’utilise la première manière car je la trouve la plus sûre. Tout dépend des besoins mais je trouve qu’une méthode add et un getter suffisent généralement.
Comme je le disais en réaction sur le blog source (réaction qui n’est pas passée apparemment).
Je ne vois pas pourquoi ne pas faire un mixe des deux. Le désavantage à la méthode “paranoïaque” est lorsque l’on utilise un ORM et que l’on veux remplir ces collections. Le désavantage de la “trust” est évidemment de ne plus contrôler la liste.
Pour celui qui le veux vraiment il est possible de faire un wrapper sur la collection et de maitriser les modifications sur celle-ci. De plus avec le types paramétrés et un bon choix du type de collection il est possible de tout maitriser.
Pour ma pars, je fais les deux, j’ai des méthodes ’setItems(..)’ et ‘getItems()’ ainsi que des ‘addItem(..)’ et ‘removeItem(..)’. L’avantage est de ne pas se casser la tête pour injecter une liste et d’avoir un code plus propre. Ainsi mon ORM peux utiliser les méthodes sur la liste (xxxItems) et une développeur peux conserver un code propre avec ‘objet.addItem(monItem)’ à la place d’un horrible ‘objet.getItems().add(monItem)’.
Je pense que si tu mixe, tu n’es plus en possession d’un POJO car tu rajoutes de “l’intelligence” à ta classe. Est ce que ton add/removeItem va lever des runtime exceptions par exemple? Vas-tu ajouter des règles de gestions particulières?
Dans certains cas je préfère laisser une liberté maximale à l’utilisateur. Je lui fournis des materiaux bruts, à lui de bien les utiliser. Ce que je veux dire par là c’est qu’une classe qui représente un objet métier ne doit pas intégrer “d’algorithmes” ou de “tests”. Pour moi c’est de la responsabilité du DAO, du service métier, ou de la classe qui va utiliser mon objet métier.
Si je peux prendre un exemple concret, en EJB3, je me vois mal mettre des add/removeItems dans mon EntityBean, par contre ce serait dans les Session Bean que j’implémenterai les add/removeItems.
Tout à fais d’accord mais ce n’est pas parce que tu vas faire un petit test pour savoir si on te passe une collection nulle que ton objet n’est plus un POJO donc je ne vois aucun problèmes à faire ce mixe.
Je crois qu’il n’y a pas de solution qui sorte particulièrement du tas. Je me souviens d’un cas où un bean pouvait être accédé par plusieurs couches de services et on avait laissé les getters/setters classiques et tous les développeurs avaient accès à ces méthodes publiques. Ca a été vite l’accident, on a dès lors changer la stratégie en créeant une classe intermédiaire qui permettait d’appeler des méthodes telles que add, get, remove, etc