A bad citizen in Javaland

I just read this wonderful post on the use of setters and getters in Java classes... that's a very good metaphore which explains why they really break encapsulation, as they actually expose the internal structure of a bean this leading to, er, "interesting" results.

Do I hear someone say "How can I then build an object if I don't have all the mandatory informations I need from the start?"? Well, to begin with that's what Builders are for. If you feel this is an issue you're probabily storing the data in the wrong class.

OOD is about collaborations, not about structures. If you stick with structures, there's some procedural programming lurking under your OO language: you're not asking services, you're instructing slaves. Slaves of which you know everything. Doesn't it smell? You have "sad" objects, as Francesco Cirillo calls them, mere value objects in disguise. That doesn't mean "Transaction Script is evil", but surely means "Transaction Script can be really evil"; it all depends on the domain and on the application you're working on.

That can sometimes lead to another common objection: "data survive applications, so that's the focal point around which everything must revolve". Curiously enough, the way data is persisted is just an implementation detail - and I'm not saying it's easy, as a matter of fact there are a lot of issues and patterns about how to deal with them on the subject. But it's not the main concern in OOD, even if generates a lot of boilerplate code.