If you put the behaviour where it belongs you won't need nearly as many getters/setters.
A friend of mine goes to a writing class. At one point, the teacher showed the class a paragraph that had problems, and went through how to fix it. My friend wrote:
Just looking at a well-written paragraph doesn't necessarily teach me anything- I want to see what not to do. By the same token, showing me something bad and not telling me *how* it could be improved is useless.
On her first point ... I think there is a lot of focus on showing how to do things right as opposed to fixing problematic designs and implementations. AntiPatterns tend to try to teach this, but the books tend to be boring (a catalog as opposed to a tutorial) or painful to read (I've seen this train wreck, and this one, etc., too depressing).
On her second point ... At one job, I was in a relatively senior position, and I was able to point out deficiencies and actually have something done about them. One coworker noted that I was able to point out problems, but not the solutions. I had hoped that bringing up the problems would lead us all to talk about them and find solutions together, but the solutions didn't always come and coworkers would sometimes get frustrated.
> I don't accept that as an excuse anymore.. with tools like > Eclipse & IDEA. They can find references to the vars.. > and often even do the switch to a getter/setter for you.
Sure, but you have to assume the only callers are within the scope of your IDE. I see this assumption break from time to time once the code escapes outside a modern IDE. If you've already released code, a versioning policy needs to be taken into account (we've got a versioning policy, right...? ;)
> "Getter/setter methods often make their way in code > because the coder was thinking procedurally. The best way > to break out of that procedural mindset is to think in > terms of a conversation between objects that have > well-defined responsibilities." > > What's needed is a solid understanding of OO. I'm > constantly amazed that, after 37 years, that's still > mostly absent!
I liked Holub's article (though he's gotten a lot of flack for that viewpoint) Ok... so you mentioned really good OO code elsewhere in this thread. Can you point to 1) a really good reference and 2) some really good OO code for people to study?
It's always easy to blame others' code but in many cases, like in mine, we are also forced to continue the trend and write more bad code. The code we inherited uses interfaces indiscriminately in the name of facilitating unit testing, not just to model "can do" relationships. The code does use the spring framework but I have an issue with any framework that makes static analysis (incl. reading) harder. My major complaint is that every other line forces me to pause and wonder which object's method is going to be invoked next.