Sebenernya ada beberapa sumber yang bilang POJO ini anti pattern...

Tapi yah sekali lagi...

What ever works for you...

 

Kalo gue lagi males bikin bean banyak2... dan kebetulan lagi pake iBatis... ya 
pake map buat represent a bean...

Simpler that way...

 

Untuk paham kenapa pake POJO instead of map... lu musti paham dulu...

Bahwa POJO ituh di bikin tujuan nya KHUSUS untuk bean ituh sendiri...

I mean... kenapa bikin segala macem map yang aneh2 belom lagi accessor dan 
modifier mechanism yang jalan untuk segala macam data object...

Padahal setiap data object pasti beda bentuk nya...

Ok sure... pasti ada abstraction buat programmer...

But what hell it would be...

 

Mendingan pake POJO... dan dibikin convention...

Dan ntar gue tinggal "safely assume" the name of the modifier method...

Gue mau access and modify student.name

So? Gue panggil getStudent().getName();

Gue baru denger PropertyValue di java5 sih... gak tau kalo dulu ada ato 
enggak...

Tapi jaman dulu gue bikin bean util yang bisa safely do this exact thing...

 

Coba case yang sama kita implement dengan Map...

Kalo student.name... jadi ada studentMap... dan key nya "name"

Kita ambil value nya...

But wait...

Gimana kalo map ini gak contain any object with the given key?

Die akan return null... bukan throw RuntimeException...

Padahal harusnya Exception khan?

 

And again...

Gimana represent inheritance kalo pake map?

You have to write the whole duplicate property all over again...

Kalo pake pojo... asal dari parent nya public... gue pake PropertyValue tetep 
ajah jalan...

Kagak pusing...

 

Ok... lalu kenapa dibilang POJO ini anti-pattern?

Basic nya OOP tuh sebenernya bahwa data dan procedure ituh level nya sama...

Jaman procedural language roam the earth dulu...

Data ituh level nya di bawah procedure...

Kenapa? Karna data di modify sama procedure...

Data ituh slave...

Kalo OOP?

Satu object(BUKAN data), object punya data DAN procedure...

Right?

Selevel khan?

Nah... lalu orang mikir security nya...

Datanya dibikin private...

Gubraaaggg balik lagi... bikin delegate accessor and modifier method...

Sama ajah boong...

Balik lagi... data nya jadi di bawah procedure level nya...

Dulu sih gue mikir sebenernya mendingan bikin property nya semua public...

Ini baru make sense...

Tapi baru lama setelah ituh gue perhatikan kegunaan nya "protected"

Heheheh

Naahh baru deh semua make perfect sense...

 

Kesimpulan nya?
back...

What ever works for you dude...

Gue personally... pake POJO... karna bisa best of both worlds...

Safe... and strict...

Tapi dengan PropertyValue gue bisa bikin die jadi dynamic...

 

 

Adelwin Handoyo  |  Senior Consultant - Wholesale Bank
Standard Chartered Bank
Plaza By The Park #06-00, 51 Bras Basah Road. Singapore (189554)
T : (65) 655 72441  | E adelwin.adel...@sc.com 

 

 

________________________________

From: jug-indonesia@yahoogroups.com [mailto:jug-indone...@yahoogroups.com] On 
Behalf Of Yudhi Karunia Surtan
Sent: Thursday, February 11, 2010 4:13 PM
To: jug-indonesia@yahoogroups.com
Subject: Re: Beda Class Sama JavaBean - WAS : (Re: [JUG-Indonesia] Re: Membuat 
Koneksi Java Mysql dari textfield)

 

  

Sorry OOT neh Nik, gw mo tanya si adelwin bentaran..

POJO ruh racun ga seh menurut lu win?

Gw cuman kepikiran kenapa ga pake Map aj yah kalo cuman buat nampung-nampung 
parameter gitu..

Emang Konsep dari pakemnya si java, Pojo dulu atau Map dulu yah?

Yah jujur seh sometimes si Pojo ini berguna juga apalagi buat DTO.

Regards,

Yudhi Karunia Surtan
--------------------------------------
Mobile (+62)-818-08347561
http://yudhikarunia.wordpress.com <http://yudhikarunia.wordpress.com> 

                Javabean ituh just a convention...

                But a very unique one at that... :p

                Kalo liat di web nya sun (baca:oracle)... katanya java bean 
ituh plain old java object...

                Yang... harus punya constructor with no parameter, 

                dan beberapa naming convention of how the getter and setter 
method should be named...

                and nothing else...

                Kenapa begini?

                Banyak framework... (spring yang udah gue bongkar... dan banyak 
pake ini... )

                Yang pake code macem gini nih...

                Contoh concrete mungkin lebih kena yah...

                class Student {

                    private String name;

                    //getter and setter

                }

                 

                Ntar di pake dengan cara gini nih...

                 

                BeanWeapper student = BeanWrapperImpl(new Student()):

                student.setPropertyValue("name", "Adelwin");

                 

                nah.. kliatan khan gunanya?

                Dan kenapa convention ini dipake banget?

                 

                Jadi... class tersebut.. BUKAN javabean...




This email and any attachments are confidential and may also be privileged.  If 
you are not the addressee, do not disclose, copy, circulate or in any other way 
use or rely on the information contained in this email or any attachments.  If 
received in error, notify the sender immediately and delete this email and any 
attachments from your system.  Emails cannot be guaranteed to be secure or 
error free as the message and any attachments could be intercepted, corrupted, 
lost, delayed, incomplete or amended.  Standard Chartered PLC and its 
subsidiaries do not accept liability for damage caused by this email or any 
attachments and may monitor email traffic.

 

Standard Chartered PLC is incorporated in England with limited liability under 
company number 966425 and has its registered office at 1 Aldermanbury Square, 
London, EC2V 7SB.

 

Standard Chartered Bank ("SCB") is incorporated in England with limited 
liability by Royal Charter 1853, under reference ZC18.  The Principal Office of 
SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In the 
United Kingdom, SCB is authorised and regulated by the Financial Services 
Authority under FSA register number 114276.

 

If you are receiving this email from SCB outside the UK, please click 
http://www.standardchartered.com/global/email_disclaimer.html to refer to the 
information on other jurisdictions.

Reply via email to