29/12/2014

ThePOJOantipatternanddatacentricdesign|Antonyh

ANTONYH
Development & stuff

About Me
Adobe AEM & CQ5
Development

JANUARY 11, 2014 by ANTONY HUTCHISON

The POJO
antipattern and
data-centric design
DEVELOPMENT
0 COMMENTS

The POJO antipattern is established when developers create plain java objects
that have no behaviour, only getters and setters. Its an insidious misuse of object
orientation and causes application code to be too data-centric in the name of datahttp://antonyh.co.uk/2014/01/thepojoantipattern/

1/4

29/12/2014

ThePOJOantipatternanddatacentricdesign|Antonyh
orientation and causes application
code to be too data-centric in the name of data-

modelling, abstraction, and persistence when there are many reasons to avoid this
style of coding.

The car analogy.

In a POJO world, imagine an interpretation of a car. Remember that you can only
use getters and setters. You might end up with something like:

Carcar=newCar()
car.setDriver(driver)
car.setPassengers(setOfPassengers)
car.setDirection(Compass.NORTH)
car.setSpeedMph(88)

All this is very well and good, expect it isnt. By error, its possible to set a speed
without a driver or a direction. It also doesnt actually do anything once its set,
theres no logic. Its like a car without an engine.
The worst part about POJOs is that its utterly pointless writing unit tests for them,
making them an antagonist in the world of TDD. They artificially change coverage
percentages purely by their presence, and help hide other code that should be
tested.

What should a car do?

A better model of a car is by its behaviour; a mode of transport.

Carcar=newCar(location)
car.drive(destination,driver,passengers)

Less code, more validation, better logic, and its still can be persisted using
serialisable variables if needed.
http://antonyh.co.uk/2014/01/thepojoantipattern/

2/4

29/12/2014

ThePOJOantipatternanddatacentricdesign|Antonyh

Why you should avoid the POJO

antipattern
Using POJOs in modern code forces the application internals to be data centric,
verbose, and obscures the logic and requirements that created the application in
the first place. Instead you should model the behaviour of the object what it does
rather than what it is. Avoiding the POJO antipattern will help in the long term as
you model behaviour and not the underlying data, and enables use of advanced
software development techniques such as the naked objects pattern for
generating user interfaces.

PREVIOUS POST

NEXT POST

Avoid creating Microsites

A reason to calibrate
colours on OS X

0Comments

antonyh.co.uk

Login

Share Favorite

SortbyBest

Startthediscussion

Bethefirsttocomment.

WHAT'STHIS?

ALSOONANTONYH.CO.UK

AnIntroductiontoCQ5forArchitects

JavaCMSRoundup

3comments10monthsago

4comments10monthsago

http://antonyh.co.uk/2014/01/thepojoantipattern/

3/4

29/12/2014

ThePOJOantipatternanddatacentricdesign|Antonyh

NitinShingneAnthonyAppreciate

AntonyHutchisonGoodpoint,Liferay

thepost.Veryhelpful.

ismissingfromthisroundup.AtthetimeI
classifieditasaportalwhenIwasmore
interestedinpureCMSproducts.This

VagrantVMsforTomcatorMongoDB
Developers

AvoidcreatingMicrosites
2comments10monthsago

2comments7monthsago

AntonyThankyou,yoursupportis

appreciated.

AntonyHutchisonIhaveanditseems

toworkwell.ThekeyistomaketheVM
disposable,sodon'tputCQ/AEMinthe
VMfilesystem(putitinthelocal

Subscribe

AddDisqustoyoursite

Privacy

PROUDLY POWERED BY WORDPRESS

THEME: EDITOR BY ARRAY

http://antonyh.co.uk/2014/01/thepojoantipattern/

4/4