Plain Old Java Object

Nell'ingegneria del software, POJO è un acronimo di Plain Old Java Object. Il nome è usato per accentuare che un oggetto dato è un oggetto ordinario Java, non un oggetto speciale. Il termine fu coniato da Martin Fowler, Rebecca Parsons e Josh MacKenzie nel settembre 2000:

Il termine "POJO" denotava inizialmente un oggetto Java che non segue nessuno dei maggiori modelli, delle convenzioni, o dei framework di oggetto Java. Oggi, si può usare POJO anche come un acronimo di "Plain Old JavaScript Object". In questo caso, il termine denota un oggetto JavaScript di genealogia simile.^[1]

Il termine continua il modello di termini più vecchi per tecnologie che non usano nuove caratteristiche fantastiche, come POTS (Plain Old Telephone Service) in telefonia, PODS (Plain Old Data Structures) definiti nel C++ ma usanti solo caratteristiche del linguaggio C, e POD (Plain Old Documentation) nel Perl. L'equivalente del POJO sul .NET Framework è Plain Old CLR Object (POCO).^[2] Per il PHP, è Plain Old PHP Object (POPO).^[3]

In teoria, un POJO è un oggetto Java non legato ad alcuna restrizione diversa da quelle costrette dalla specifica del linguaggio Java (Java Language Specification). In altre parole, è imperativo che un POJO:

1. non estenda delle classi prespecificate, come in

   public class Foo extends javax.servlet.http.HttpServlet { ...
   

2. non implementi delle interfacce prespecificate, come in

   public class Bar implements javax.ejb.EntityBean { ...
   

3. non contenga delle annotazioni prespecificate, come in

   @javax.persistence.Entity public class Baz { ...
   

Tuttavia, a causa di difficoltà tecniche e altre ragioni, molti programmi o molti framework descritti come conformi a POJO in realtà richiedono ancora l'uso di annotazioni prespecificate per caratteristiche quali persistenza per un corretto funzionamento. L'idea è che se l'oggetto (in realtà classe) era un POJO prima dell'aggiunta di qualsiasi annotazione e potesse tornare allo status di POJO se si eliminassero le annotazioni, allora può ancora essere considerato un POJO. Dunque l'oggetto di base rimane un POJO nel senso che non ha delle caratteristiche speciali (come un'interfaccia implementata) che lo rendono un "Specialized Java Object" (SJO o (sic) SoJO).

Lo stesso argomento in dettaglio: JavaBean.

Un JavaBean è un POJO che è serializzabile, ha un costruttore senza argomenti e consente l'accesso a proprietà utilizzando metodi getter e setter che seguono una semplice nomenclatura convenzionata. A causa di questa convenzione si possono fare delle semplici referenze dichiarative a proprietà arbitrarie di JavaBeans. Un codice utilizzante tale referenza dichiarativa non sa nulla del tipo del bean (oggetto singolo) e si può utilizzare il bean con molti framework senza che questi framework abbiano accesso al tipo esatto del bean.

La specificazione di JavaBeans, se pienamente implementata, viola leggermente il modello POJO (come la classe deve implementare l'interfaccia Serializable) a essere un vero JavaBean. Molte classi di POJO ancora nominate JavaBeans non soddisfano detto requisito. A causa del fatto che Serializable è un'interfaccia senza metodo, questo non è un onere.

Il codice seguente mostra un esempio di un componente di Java Server Faces (JSF) avente un bidirezionale legante a un proprietà di POJO:

<h:inputText value="#{mioBean.alcunaProprieta}"/>

La definizione del POJO può essere espresso come segue:

public class MioBean 
{
	private String alcunaProprieta;

	public String getAlcunaProprieta() 
	{
		return alcunaProprieta;
	}

	public void setAlcunaProprieta(String alcunaProprieta) 
	{
		this.alcunaProprieta = alcunaProprieta;
    }
}

A causa delle convenzioni di nominare in JavaBean l'unica referenza alcunaProprieta può essere tradotta automaticamente al metodo getAlcunaProprieta() (o isAlcunaProprieta() se la proprietà è di tipo booleano) per ottenere un valore, e al metodo setAlcunaProprieta(String) per mettere un valore.

Portale Informatica: accedi alle voci di Wikipedia che trattano di Informatica