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 quelque restriction autre qui celles-là forcées par la Java Language Specification. En autres mots, 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 accordanti avec POJO encore demandent en effet l'usage des annotations préspécifiées pour telles caractéristiques comme persistance pour fonctionner correctement. L'idée est que si l'objet (en effet la classe) fosses un POJO avant que quelques annotations fussent ajoutées, et retournerait à l'état de POJO si les annotations sont enlevées, alors peut être considéré un POJO encore. Alors l'objet basique reste un POJO dans le sens qui n'a pas caractéristiques spéciales (comme une interface implémentée) qu'ils le font un "Specialized Java Object" (SJO o (sic) SoJO).
