Plain old Java object

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.

Pour les articles homonymes, voir Pojo.

Description

Le terme a été inventé par Martin Fowler, Rebecca Parsons et Josh MacKenzie en .

« Nous nous sommes demandé 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 lié à aucune autre restriction que celles forcées par la spécification du langage Java. En d'autres termes, il est impératif qu'un POJO :

  1. n'étende pas des classes pré-spécifiées, comme dans
    public class Foo extends javax.servlet.http.HttpServlet { ...
  2. n'implémente pas des interfaces pré-spécifiées, comme dans
    public class Bar implements javax.ejb.EntityBean { ...
  3. 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 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 la classe) était un POJO avant d'ajouter toute annotation, et revient à l'état de POJO si les annotations ont été éliminées, alors il peut encore être considéré comme un POJO. Ainsi, 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 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 dont les noms sont déterminés par une convention simple. À 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 que ces frameworks aient à connaître le type exact du bean.

La spécification de JavaBeans, ainsi pleinement implémentée, viole légèrement le modèle POJO qui devrait être un vrai JavaBean, car la classe doit implémenter l'interface Serializable. Des nombreuses classes de POJO encore nommées JavaBeans ne satisfont pas à cette exigence. Puisque Serializable est une interface sans méthode, ce n'est pas un fardeau.

Le code suivant montre un exemple d'un composant de JSF ayant un bidirectionnel liant à une 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;
	}
}

Grâce aux conventions de nommage de JavaBean, la référence unePropriete peut être traduite automatiquement en un appel à 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.

Notes et références
  1. www.martinfowler.com

Voir aussi

Liens externes
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.