3 ms·

Getters and setters aren't object-oriented, and for that matter they aren't good examples of encapsulation, either. It varies from case to case, but cherry-pick

Getters and setters aren't object-oriented, and for that matter they aren't good examples of encapsulation, either. It varies from case to case, but cherry-picking, if I have an account, I don't care whether I write account.balance = $100 or account.setBalance($100). What I ought to be doing is defining semantically rich methods such as account.deposit($100).

artsrc 16y ago
What you ought to be doing is making trade offs that make sense for your situation without following any particular religion. Not OO (Object Oriented) is high praise in situations where the OO solution would be worse. All heuristics should be ignored if it suits the situation to ignore them. OO is one of many a heuristics for software design. Sometimes a deposit abstraction is simply a waste of conceptual budget and is best avoided.
- deleted 16y ago
  [deleted]
arkanis 16y ago
I agree that getters and setters aren't object oriented. It was the whole point of my blog post to make people think about that. It wasn't written for people who already understand that, though… otherwise it would be quite a bit shorter. ;) The sad thing is that way to much people think "getters and setters" when they hear "object orientation". Maybe even "Eclipse will do that for me". Needless to say that encapsulation isn't understood then, too. But encapsulation is bigger topic of it's own and would have been to much for that post. While talking about that with other people I got the impression that just explaining the way it was meant to be does not work well. Especially if a professor and many books tell otherwise. Therefore I try to make people think for their own about the problem. Showing the problem, how it is solved and how it can be solved in other situations. I don't know if I succeeded in that.
- raganwald 16y ago
  Well, I upvoted the article and I think I tweeted it as well. So it passed the "It made me think" test, thank you!

artsrc 16y ago

What you ought to be doing is making trade offs that make sense for your situation without following any particular religion. Not OO (Object Oriented) is high praise in situations where the OO solution would be worse. All heuristics should be ignored if it suits the situation to ignore them. OO is one of many a heuristics for software design. Sometimes a deposit abstraction is simply a waste of conceptual budget and is best avoided.

deleted 16y ago
[deleted]

arkanis 16y ago

I agree that getters and setters aren't object oriented. It was the whole point of my blog post to make people think about that. It wasn't written for people who already understand that, though… otherwise it would be quite a bit shorter. ;) The sad thing is that way to much people think "getters and setters" when they hear "object orientation". Maybe even "Eclipse will do that for me". Needless to say that encapsulation isn't understood then, too. But encapsulation is bigger topic of it's own and would have been to much for that post. While talking about that with other people I got the impression that just explaining the way it was meant to be does not work well. Especially if a professor and many books tell otherwise. Therefore I try to make people think for their own about the problem. Showing the problem, how it is solved and how it can be solved in other situations. I don't know if I succeeded in that.

raganwald 16y ago
Well, I upvoted the article and I think I tweeted it as well. So it passed the "It made me think" test, thank you!