Plain Old Java Object: differenze tra le versioni

Versione delle 17:08, 26 ott 2014

Versione attuale delle 21:57, 13 nov 2024

(17 versioni intermedie di 16 utenti non mostrate)

Riga 1:

Nell'[[ingegneria del software]], '''''POJO''''' è un [[acronimo]] di '''Plain Old Java Object'''. Il nome è usato per accentuare che un [[Oggetto (informatica)|oggetto]] dato è un oggetto ordinario [[Java (linguaggio di programmazione)|Java]], non un oggetto speciale. Il termine fu coniato da [[Martin Fowler]], Rebecca Parsons e Josh MacKenzie innel settembre 2000:

{{citazione

<blockquote>

|Ci domandavamo perché le persone si opponessero tantissimo ad usare oggetti regolari nei loro sistemi ed abbiamo concluso che era perché gli oggetti semplici non avevano un nome accattivante. Allora gliene abbiamo dato uno che ha preso molto piede.

''We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.''

|{{Cita web|url=http://msdnwww.microsoftmartinfowler.com/en-usbliki/library/cc681329POJO.aspxhtml |titolo=POCOMF Bliki: SupportPOJO |sito=microsoftMartinFowler.com |accesso=2422 agosto 2014}}

''|We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.''

|lingua=en

}}

(Il termine "POJO"Ci domandavamodenotava perchéinizialmente gliun uominioggetto siJava opponesseroche tantissimonon adsegue usarenessuno oggettidei regolarimaggiori neimodelli, lorodelle sistemiconvenzioni, edo abbiamodei concluso''[[framework]]'' chedi eraoggetto perchéJava. adOggi, oggettisi semplicipuò usare ''POJO'' èanche mancatacome unaun denominazioneacronimo di fantasia."Plain DunqueOld abbiamoJavaScript Object". datoIn loroquesto unacaso, eil quellotermine èdenota diventatoun popolareoggetto molto[[JavaScript]] benedi genealogia simile.")<ref name="bliki">{{Cita web|url=http://www.martinfowlerajaxian.com/blikiarchives/POJO.htmlreturn-of-the-pojo-plain-ole-javascript |titolo=MFReturn Bliki:of the POJO: Plain ‘Ole JavaScript |sitodata=MartinFowler.com17 luglio 2006 |accesso=2223 agosto 2014}}</ref>

</blockquote>

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 (linguaggio di programmazione)|C]], e POD (Plain Old Documentation) nel [[Perl]]. L'equivalente del POJO sul [[.NET Framework]] è [[Plain Old CLR Object]] (POCO).<ref>

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.<ref> {{Cita web|url=http://ajaxian.com/archives/return-of-the-pojo-plain-ole-javascript |titolo=Return of the POJO: Plain ‘Ole JavaScript |data=17 luglio 2006 |accesso=23 agosto 2014}} </ref>

{{Cita web|url=https://msdn.microsoft.com/en-us/library/cc681329.aspx|titolo=POCO Support|sito=microsoft.com|lingua=en|accesso=24 agosto 2014}}

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 (linguaggio di programmazione)|C]], e POD (Plain Old Documentation) nel [[Perl]]. L'equivalente del POJO sul [[.NET Framework]] è [[Plain Old CLR Object]] (POCO).<ref>

{{Cita web|url=http://msdn.microsoft.com/en-us/library/cc681329.aspx |titolo=POCO Support |sito=microsoft.com |accesso=24 agosto 2014}}

</ref> Per il [[PHP]], è Plain Old PHP Object (POPO).<ref>

{{Cita web|url=http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/ |titolo=typesafe objects in PHP |autore=Jan Kneschke |sito=kneschke.de|data=19 febbraio 2007 |sitolingua=kneschke.de en|accesso=24 agosto 2014|urlarchivio=https://web.archive.org/web/20120326195616/http://jan.kneschke.de/2007/2/19/typesafe-objects-in-php/|dataarchivio=26 marzo 2012|urlmorto=sì}}</ref>

== Definizione ==

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:

#non estenda delle classi prespecificate, come in <sourcesyntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { ...</sourcesyntaxhighlight>

#non implementi delle interfacce prespecificate, come in <sourcesyntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { ...</sourcesyntaxhighlight>

#non contenga delle [[Annotazione (Java)|annotazioni]] prespecificate, come in<sourcesyntaxhighlight lang="java">@javax.persistence.Entity public class Baz { ...</sourcesyntaxhighlight>

Tuttavia, a causa di difficoltà tecniche ede 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 (informatica)|interfaccia]] implementata) che lo rendono un "Specialized Java Object" (SJO o ([[sic]]) {{Sic|SoJO}}).

== Variazioni contestuali ==

=== JavaBeans ===

{{Vedi anche|JavaBean}}

Un JavaBean è un POJO che è [[Serializzazione|serializzabile]], ha un [[Costruttore (informatica)|costruttore]] senza argomenti e consente l'accesso a proprietà utilizzando [[Metodo (programmazione)|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 <code>Serializable</code>) a essere un vero JavaBean. Molte classi di POJO ancora nominate JavaBeans non soddisfano detto requisito. A causa del fatto che <code>Serializable</code> è un'interfaccia senza metodo, questo non è un onere.

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

<syntaxhighlight lang="xml" copy=1><h:inputText value="#{mioBean.alcunaProprieta}"/></syntaxhighlight>

La definizione del POJO può essere espresso come segue:

<syntaxhighlight lang="java" line="1" copy=1>

public class MioBean

{

private String alcunaProprieta;

public String getAlcunaProprieta()

{

return alcunaProprieta;

}

public void setAlcunaProprieta(String alcunaProprieta)

{

this.alcunaProprieta = alcunaProprieta;

}

}

</syntaxhighlight>

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

== Note ==

<references/>

{{Portale|Informatica}}

==Referenze==

{{Reflist}}

[[Categoria:Java]]