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).
Variations contextuelles
JavaBeans
Un JavaBean est un POJO qui est sérialisable, a un constructeur sans arguments, et permet l'accès à des propriétés utilisant des méthodes getter et setter lesquelles suivent une convention simple de nommer. À cause de cette convention, on peut faire des références simples déclaratives aux propriétés de JavaBeans arbitraires. Un code utilisant une telle référence déclarative ne sait rien du type du bean (seul objet), et on peut utiliser le bean avec de nombreux frameworks sans ces frameworks ayants à connaître le type exact du bean.
La spécification de JavaBeans, si pleinement implémentée, légèrement viole le modèle POJO comme la classe doit implémenter l'interface sérialisable à être un vrai JavaBean. Des nombreuses classes de POJO encore nommées JavaBeans ne satisfont pas à cette exigence. À cause de ce que sérialisable est une interface marque (sans méthode), ce n'est pas un fardeau.
Le code suivant montre un example d'un composant de JSF ayant un bidirectionnel liant à un propriété de POJO:
<h:inputText value="#{monBean.unePropriete}"/>
La définition du POJO peut s'exprimer comme suit:
public class MonBean
{
private String unePropriete;
public String getUnePropriete()
{
return unePropriete;
}
public void setUnePropriete(String unePropriete)
{
this.unePropriete = unePropriete;
}
}
À cause des conventions de nommer in JavaBean la seule référence "unePropriete" peut être traduite automatiquement à la méthode getUnePropriete() (ou isUnePropriete() si la propriété est de type booléen) pour obtenir une valeur, et à la méthode setUnePropriete(String) pour mettre une valeur.
