Tests are meant to ensure behavior. Not data structure. However, most behaviour would have to work with some data structures.
One thing I learnt from TDD is that your POJOs test coverage are automatically covered by the logic that’s working against it.
(Gasp! That’s a design smell on itself which is why I hate POJOs. They pretend to be objects wherein in fact, they’re just data structures. Both OOP and Procedural practice loose coupling and tight cohesion principally. The main difference is what they consider to be tightly coupled. In procedural, data and behaviour are separated. That’s because there is no one owner of the data. In OOP, the data and the behaviour that acts on it needs to be in one Object. That way, you enforce abstraction and encapsulation because the data is just part of the implementation details.)
I always understood "POJO" to mean "Plain old java object" and first saw it with the introduction of Spring where Services were just "POJOs" ie. they didn't inherit from some weird framework but used inversion of control to get other services injected. So POJO to me meant just plain old java objects without weird framework dependencies. (en.wikipedia.org/wiki/Plain_old_Ja...)
What is being discussed here is a "Value object" an object that just has getters/setters that stores data, and in that sense is nothing more than a glorified struct. (en.wikipedia.org/wiki/Value_object)
A software developer. I'm interested in learning new technologies and core language features. I love to dive into legacy code writing tests and refactoring as I go.
Tests are meant to ensure behavior. Not data structure. However, most behaviour would have to work with some data structures.
One thing I learnt from TDD is that your POJOs test coverage are automatically covered by the logic that’s working against it.
(Gasp! That’s a design smell on itself which is why I hate POJOs. They pretend to be objects wherein in fact, they’re just data structures. Both OOP and Procedural practice loose coupling and tight cohesion principally. The main difference is what they consider to be tightly coupled. In procedural, data and behaviour are separated. That’s because there is no one owner of the data. In OOP, the data and the behaviour that acts on it needs to be in one Object. That way, you enforce abstraction and encapsulation because the data is just part of the implementation details.)
Are we using terminology correctly here?
I always understood "POJO" to mean "Plain old java object" and first saw it with the introduction of Spring where Services were just "POJOs" ie. they didn't inherit from some weird framework but used inversion of control to get other services injected. So POJO to me meant just plain old java objects without weird framework dependencies. (en.wikipedia.org/wiki/Plain_old_Ja...)
What is being discussed here is a "Value object" an object that just has getters/setters that stores data, and in that sense is nothing more than a glorified struct. (en.wikipedia.org/wiki/Value_object)
Am I getting my terminology wrong?
It's more that people commonly misuse the term POJO so that in common slang usage it really could mean any of POJO, JavaBean, value object, or more.
I always thought of value objects as immutable (no setters). A POJO can have setters. I think lombok's @Data and @Value provide good standards.
It may be a good practice for a value object to be immutable but it's not required.
POJO just means any Java object that doesn't depend on a weird framework.