The POJO antipattern is established when developers create plain java ‘objects’ that have no behaviour, only getters and setters. It’s an insidious misuse of object 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:
Car car = new Car(); car.setDriver(driver); car.setPassengers(setOfPassengers); car.setDirection(Compass.NORTH); car.setSpeedMph(88);
All this is very well and good, expect it isn’t. By error, it’s possible to set a speed without a driver or a direction. It also doesn’t actually do anything once it’s set, there’s no logic. It’s like a car without an engine.
The worst part about POJOs is that it’s 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 it’s behaviour; a mode of transport.
Car car = new Car(location); car.drive(destination, driver, passengers);
Less code, more validation, better logic, and it’s still can be persisted using serialisable variables if needed.
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.