Live data from Hacker News

Are getters and setters object oriented?

arkanis.de

31–35 of 35 posts

Re: Are getters and setters object oriented?

#31

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).

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.

Re: Are getters and setters object oriented?

#32
post #9

Using property overloading to implement getters/setters in PHP is terrible practice. It's slow, makes the code hard to manage and introduces unexpected behavior. function __set($property, $value){ if ($property == 'speed'){ // ... } } Just write the damn setter or no setter at all but please don't use property overloading for this! function setSpeed($value) {}

His implementation leaves much to be desired, but there are better ways of doing it. http://pastebin.com/JiEXp6Za

The example is the most simple way I could think of. It should only show that is is possible not what is the perfect solution (if there is any).

Of course you could throw in some runtime reflection and variable function calls to make it more maintainable. However for me it needs to pay of… I don't want to maintain such a system for just a hand full of properties. I like to keep complexity "flat" and so I often stick to the direct language features. But on large projects the code you linked could really come in handy. Thanks. :)

Re: Are getters and setters object oriented?

#33
post #9

Using property overloading to implement getters/setters in PHP is terrible practice. It's slow, makes the code hard to manage and introduces unexpected behavior. function __set($property, $value){ if ($property == 'speed'){ // ... } } Just write the damn setter or no setter at all but please don't use property overloading for this! function setSpeed($value) {}

I would be interested in why it is considered a terrible practice.

That it's slow might be a good point but for performance critical stuff I use D and for larger web project Ruby on Rails (where performance is a whole different topic). PHP is my tool of choice for small and compact web projects and since I try to keep them as simple as possible performance isn't that much of a concern. Anyway I did a small benchmark and was a bit surprised:

direct access: 0.276369s getter access: 0.540416s property overloading access: 0.825164s

Of course I can publish the benchmark source if someone is interested. It basically accesses a property 1000000 times adds the returned value to a sum (so that it's not optimized away… just in case).

The overhead looks ok for me. 1 out of 5 properties can be redirected via property overloading before its performance is worse than getter methods. I don't really know much about the internals of large PHP projects but I you can avoid most "empty" getter and setter methods and handle the view exceptions with property overloading performance seems fine for me.

Unexpected behavior might be a problem. However not existing properties still return NULL. The only difference is that no notice is generated… and that can be easily done with one line at the end of the __get() and __set() functions. Management of "raw" property overloading can be troublesome for a larger number of properties. However you can simply add some runtime reflection to call a corresponding getter function. But in that case I would start to think about the interface and if I might have done something wrong (in regards to encapsulation).

Having spend much time in the Ruby world I really like the kind of interfaces you can build with property overloading (like SimpleXML). For me more fluid handling like that is worth the performance cost.

Re: Are getters and setters object oriented?

#34
post #21

Getters and Setters violate encapsulation just as much as accessing properties directly, so I don't bother with them unless I'm forced to. In languages like C++ they can make sense due to a need of allocating and freeing memory of things within the object, but it's still not OOP. What you have when you're using getters and setters is a fancy struct with methods, not an OO class. (There is a significant difference.) S…

I very much agree, but saying it in such a way won't help others to understand that. That is persons that haven't understood the significant difference right now.

Re: Are getters and setters object oriented?

#35
post #31

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).

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 encapsulat…

Well, I upvoted the article and I think I tweeted it as well. So it passed the "It made me think" test, thank you!
Post reply on HN