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 théorie, un POJO est un objet Java non lié à aucune restriction autre que celles forcées par la spécification du langage Java (Java Language Specification). En d'autres termes, il est impératif qu'un POJO:
- n'étende pas des classes pré-spécifiés, comme en
public class Foo extends javax.servlet.http.HttpServlet { ...
- n'implémente pas des interfaces pré-spécifiées, comme en
public class Bar implements javax.ejb.EntityBean { ...
- ne contienne pas des annotations pré-spécifiées, comme dans
@javax.persistence.Entity public class Baz { ...
Toutefois, à cause de difficultés techniques et d'autres raisons, plusieurs programmes ou frameworks décrits comme conformes à POJO en fait nécessitent encore l'utilisation des annotations pré-spécifiées pour les caractéristiques telles que la persistance pour un fonctionnement correct. L'idée, c'est que si l'objet (en fait classe) était un POJO avant d'ajouter toute annotation, et revienne à l'état de POJO si les annotations ont été éliminés, alors il peut encore être considéré comme un POJO. Donc l'objet de base reste un POJO dans le sens où il n'a pas des caractéristiques spéciales (comme une interface implémentée) qui font de lui un "Specialized Java Object" (SJO ou (sic) Sojo).
