Da malo recikliram temu POCO/POJO objekata, nakon 10 godina i repostiram/preuredim kratki tekst sa starog bloga. I to nije samo da bih objavio bilo kakav novi post, nego, zaista, još uvijek se ovaj pojam jako često loše upotrebljava i od toga mi se diže kosa na glavi.
Uviđam da masa, čak i iskusnih developera pogrešno shvata ovaj pojam.
POCO objekti nam dolaze iz Java svijeta, gdje se zovu POJO – Plain Old Java Object.
U .NET svijetu, POCO skraćenica znači Plain Old CLR Object (često se označavaju kao Plain Old C# Object – što je pogrešno – jer se mogu praviti u bilo kom .NET jeziku).
Mnogi pogrešno razumijevaju da su to objekti koji nemaju ponašanje (behavior) – već su sastavljeni samo od podataka (atributi i getteri/setteri). Pošto se često upada u zamku kreiranja Anemic Domain Modela [Fowler], posebno u .NET svijetu, takva predstava o POCO objektima se savršeno uklapa u priču.
Činjenica je da takve objekte (mislim, bez ponašanja, ne POCO) po pravilu ne treba praviti, te da to nema puno veze sa OOP-om uopšte – takvo nešto možete napraviti i sa strukturama. Rijetke su situacije u kojima se objekti bez ponašanja primjenjuju, kao što je Data Transfer Object [Fowler], ali to je posebna priča (isti najčešće nisu POCO). U svakom slučaju, da li je neki objekat POCO ili ne, nema veze s time da li on ima ponašanje ili nema.
Šta su onda POCO/POJO?
To su objekti klasa koji nisu dizajnirani za korištenje s nekim specifičnim frameworkom, pa stoga nisu opterećeni nasljeđivanjem neke određene klase, ili implementiranjem nekih određenih interfejsa koje propisuje framework. Primjeri objekata koji nisu POCO/POJO su EJB kod Jave, MarshalByRef objekti kod .NET-a, objekti ukrašeni [Serializable] atributom i sl. Da bi objekat bio POCO, njegova klasa ne može:
- Nasljeđivati neku određenu klasu koju propisuje framework
- Implementirati neki određeni interfejs koji propisuje framework
- Biti označen nekim specifičnim atributom koji propisuje framework
Praktično, objekat mora biti neovisan i “nesvjestan” korištenja bilo kakvog framework infrastrukturnog mehanizma.
Naravno, to ni u kom slučaju ne znači da da takva klasa ne može nasljeđivati ili implementirati ništa, ili da ne smije koristiti atribute. Naprotiv, ona može normalno imati bilo kakvu relaciju sa klasama unutar modela same aplikacije.
Poželjno je da npr. Domain Model objekti budu POCO, ali to nikako ne isključuje nasljeđivanje, interfejse, i naravno – ponašanje – što je osnova Rich Domain Modela.