 |
|
|
| |
| PRATIQUE JAVA |
|
|
|
| Expliquez-moi... POJO, le retour à la simplicité de Java |
| |
| Utiliser des Plain Old Java Object afin de découpler son code des interfaces invasives et complexes des frameworks et bibliothèques à la mode.
(01/09/2006) |
  |
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
L'acronyme POJO, pour Plain Old Java Object (traduisible par "Java Objet,
tout simplement"), est couramment utilisé aujourd'hui pour parler
du mouvement visant à simplifier le plus possible la conception
d'une application Java. Pour ce faire, les partisans de POJO
encouragent les développeurs à se reposer sur un minimum de
bibliothèques de codes. Par définition, un POJO est un objet
n'implémentant pas d'interface spécifique à un
framework.
L'idée
est née lorsqu'il a semblé évident que la principale raison
pour laquelle les développeurs préféraient faire appel à des
objets EJB - plutôt que de travailler avec des objets Java
ordinaires mais tout aussi efficaces -, était que cette dernière
méthode de permettait simplement pas de se vanter d'avoir utilisé
un acronyme..
Le terme est devenu très en vogue, et ne vise plus aujourd'hui directement le framework EJB, mais tous les frameworks compliqués ou spécialisés qui enferment les développeurs dans leurs usages, contrairement à un usage extensif de la bibliothèque standard de Java.
Avant toute chose, la popularité du concept POJO amène les développeurs à se poser plus régulièrement la question du gain réel de l'usage d'un framework face à son coût en complexité. La plupart des frameworks utilisent aujourd'hui des POJOs pour simplifier leur usage et éviter de contaminer le code du développeur avec leurs propres objets.
Ainsi, les frameworks Spring, EJB3, Hibernate ou JDO en font fortement usage. Il devient dès lors possible d'utiliser les composants de ces frameworks sans pour autant coupler intrinsèquement ses propres objets avec les interfaces invasives de ces derniers, par exemple, et donc de s'assurer de pouvoir reprendre en main le code plus facilement, fut-il nécessaire un jour de ne plus modifier ce framework particulier.
Il reste donc possible d'utiliser les transactions, la persistance Objet et de sécuriser son application par le biais de ces frameworks, tout en ne faisant appel qu'à des objets Java classiques. L'astuce se trouve dans l'injection d'une dépendance au sein des paramètres du constructeur d'un objet. |
|
|
|
|
|
|
