Obiect vechi Java simplu

În ingineria software , POJO este un acronim pentru Plain Old Java Object . Numele este folosit pentru a sublinia că un obiect dat este un obiect Java obișnuit, nu un obiect special. Termenul a fost inventat de Martin Fowler , Rebecca Parsons și Josh MacKenzie în septembrie 2000:

Termenul „POJO” desemna inițial un obiect Java care nu urmează niciunul dintre principalele modele de obiecte Java, convenții sau cadre . Astăzi, „POJO” poate fi folosit și ca acronim pentru „Obiect JavaScript simplu vechi”. În acest caz, termenul denotă un obiect JavaScript de genealogie similară. ^[1]

Termenul continuă modelul termenilor mai vechi pentru tehnologiile care nu utilizează funcții noi fantastice, cum ar fi POTS ( Plain Old Telephone Service ) în telefonie , PODS ( Plain Old Data Structures ) definite în C ++, dar folosind doar caracteristici de limbaj C și POD (Plain Old Documentation) în Perl . Echivalentul POJO pe .NET Framework este Plain Old CLR Object (POCO). ^[2] Pentru PHP , este obiectul simplu vechi PHP (POPO). ^[3]

Definiție

În teorie, un POJO este un obiect Java care nu este legat de alte restricții decât cele impuse de specificația Java Language. Cu alte cuvinte, este imperativ ca un POJO:

1. nu extinde unele clase prespecificate, ca în

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

2. nu implementați interfețe pre-specificate, ca în

    public class Bar implementează javax . ejb . EntityBean { ...
   

3. nu conține adnotări pre-specificate, ca în

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

Cu toate acestea, din cauza dificultăților tehnice și a altor motive, multe programe sau cadre descrise ca fiind conforme cu POJO necesită în continuare utilizarea unor adnotări pre-specificate pentru caracteristici precum persistența pentru o funcționare corectă. Ideea este că, dacă obiectul (de fapt clasa) a fost un POJO înainte de adăugarea oricăror adnotări și ar putea reveni la starea POJO dacă adnotările au fost șterse, atunci acesta poate fi considerat în continuare un POJO. Deci obiectul de bază rămâne un POJO în sensul că nu are caracteristici speciale (cum ar fi o interfață implementată) care îl fac un „obiect Java specializat” (SJO sau (sic) SoJO).

Variații contextuale

JavaBeans

Un JavaBean este un POJO care este serializabil , are un constructor fără argumente și permite accesul la proprietăți folosind metode getter și setter care urmează o nomenclatură convențională simplă. Datorită acestei convenții, se pot face trimiteri declarative simple la proprietățile arbitrare ale JavaBeans. Un cod care utilizează această referință declarativă nu știe nimic despre tipul de bean (obiect unic) și puteți utiliza beanul cu multe cadre fără ca aceste cadre să aibă acces la tipul exact al beanului .

Specificația JavaBeans, atunci când este complet implementată, încalcă ușor modelul POJO (deoarece clasa trebuie să implementeze interfața serializabilă) pentru a fi un adevărat JavaBean. Multe clase POJO numite în continuare JavaBeans nu îndeplinesc această cerință. Datorită faptului că Serializable este o interfață fără metode, aceasta nu este o povară.

Următorul cod prezintă un exemplu de componentă JSF care are o legătură bidirecțională la o proprietate a POJO:

 <h: inputText value = "# {myBean.someProperties}" />

Definiția POJO poate fi exprimată după cum urmează:

 clasa publică MioBean 
{
	private String someProperty ;

	public String getSomeProperty () 
	{
		returnează unele Proprietăți ;
	}

	public void setSomeProperty ( String someProperty ) 
	{
		aceasta . someProperty = uneleProprietate ;
    	}
}

Datorită convențiilor de denumire în JavaBean, singura referință „someProperty” poate fi tradusă automat în metoda getSomeProperty () (sau isSomeProperty () dacă proprietatea este de tip boolean ) pentru a obține o valoare și în metoda setSomeProperty (String) a pune o valoare.

Notă

Portal IT : accesați intrările Wikipedia care se ocupă cu IT