Plain old Java object
Cet article est une ébauche concernant l’informatique.
Pour les articles homonymes, voir Pojo.
POJO est un acronyme qui signifie Plain Old Java Object que l'on peut traduire en français par bon vieil objet Java. Cet acronyme est principalement utilisé pour faire référence à la simplicité d'utilisation d'un objet Java en comparaison avec la lourdeur d'utilisation d'un composant EJB. Ainsi, un POJO n'implémente pas d'interface spécifique à un framework comme c'est le cas par exemple pour un composant EJB.
Description
Le terme a été inventé par Martin Fowler, Rebecca Parsons et Josh MacKenzie en septembre 2000. « Nous nous sommes demandés pourquoi tout le monde était autant contre l'utilisation d'objets simples dans leurs systèmes et nous avons conclu que c'était parce que ces objets simples n'avaient pas un nom sympa. Alors, on leur en a donné un et ça a pris tout de suite. »[1]. Le terme est une continuation des anciens schémas de nommage (pattern) de termes plus anciens mais qui n'utilisent pas de propriétés nouvelles, tels que les POTS (pour Plain Old Telephone Service) en téléphonie, et les PODS (pour Plain Old Data Structures) définis en C++ mais qui n'utilisent que des propriétés du langage C.
L'équivalent du POJO dans le framework .NET est le POCO (Plain Old CLR Object), pour PHP le POPO (Plain Old PHP Object), et PONSO pour l'Objective-C (Plain Old NSObject).
Définition
En parlant idéalement, un POJO est un objet de Java ne limité pas par d'autres restrictions que celles qui sont forcées par la Java Language Specification. C'est-à-dire, un POJO doit:
- Ne pas étendre des classes préspécifiées, comme en
public class Foo extends javax.servlet.http.HttpServlet { ...
- Ne pas implémenter des interface préspécifiées, comme en
public class Bar implements javax.ejb.EntityBean { ...
- Ne pas contenir des annotations préspécifiées, comme en
@javax.persistence.Entity public class Baz { ...
Cependant, à cause des difficultés techniques et les autres raisons, beaucoup de produits de logiciel ou beaucoup de framework décrits comme accordants avec POJO encore demandent en effet utilisation des annotations préspécifiées pour telles caractéristiques comme persistance pour fonctionner correctement. L'idée est que si l'objet (la classe en fait) était un POJO avant que quelques annotations ont été ajoutées, et retournerait à l'état de POJO si les annotations sont retirées, alors peut être considéré comme un POJO. Ensuite, l'objet basique est un POJO en ce sens que n'a pas caractéristiques particulières (comme une interface implémentée) qui le font un "Specialized Java Object" (SJO o (sic) SoJO).
