In most definitions, POJO (Plain Old Java Object) is object with properties along with just getters/setters. Some people name these DTO. So essentially they are what i like to call them 'Data classes'. Whatever the name is i know there are these kind of objects where it just have getters/setters. And these are commonly used within developing multi-layered MVC web applications - where these objects would be passed through the different layers.
Maybe my question is a bit towards opinionated - but is this pure OOP or not? I'm determined to find out the answer to this i.e. what's right and what's wrong?
...Because, i have been brought up learning that OOP is all about modelling real-life scenarios/situations into objects through interaction. With objects themselves encapsulate data and behaviour which acts on this data. - an object with just getters/setters doesn't fit into this definition in my opinion.
Also, data classes are bad (code smell) - that's what i've been taught in university.
There's no such thing as pure OOP. How people worked with OO changed over the years.
I'm more inclined to add behaviour to my types (https://en.wikipedia.org/wiki/Domain-driven_design). If you treat a type as a datacontainer (POJO) you'll need to put that behaviour somewhere. Usually something called xxxService. That's an extra level of indirection just to do something which may be the core business of that "POJO".
After writing some more code you may end up with having the need for this function somewhere else. Now you'd need to extract this to some helper which you can share. Which means you'll have like 2 services calling the same method acting upon your POJO. Another level of indirection added.
But that's one way of doing it. I've worked on quite a few projects and a lot of developers feel more comfortable with the setter/getter thing. If you have a team which feels more comfortable with setters/getters, why not. It won't kill the project but you'll have to see it every day ;)