Live data from Hacker News

Why you shouldn't use getters and setters on Android

blog.leocad.io

11–13 of 13 posts

Re: Why you shouldn't use getters and setters on Android

#11
post #4

So, calling a "getter" method is slower (x1.5 to x2) than directly accessing a private field. Nothing new here: everyone with a fair understanding of how computers work should know that calling a [virtual] function is a more complex operation than accessing a field, hence it takes more time to complete. It's actually reassuring to know that it's only x1.5 to x2 slower, so thanks to the OP for figuring that. However t…

I've never found this argument very convincing. By adding the methods "string get_Name()" and "void set_Name(string name)" you are making _exactly_ the same contract as if you have "public string Name". There is no extra dependency here - the dependencies are identical.

I always thought the point was not that you can do the exact same thing but that you don't care if it is doing the same thing or something crazy complicated to return something to you.

OOP works much better in teams and is a bit/lot of overhead when you are making contracts with yourself.

However if I'm working with someone and they tell me call this to get a name then ill do that, if later they realize they need to split out the name into first and last I can still use that old function to get the full name by them combining the strings and returning that in that old "getter".

PS that might be a very poor example, hopefully you get my point :)

Re: Why you shouldn't use getters and setters on Android

#12
post #11

Earlier quoted context omitted.

I've never found this argument very convincing. By adding the methods "string get_Name()" and "void set_Name(string name)" you are making _exactly_ the same contract as if you have "public string Name". There is no extra dependency here - the dependencies are identical.

I always thought the point was not that you can do the exact same thing but that you don't care if it is doing the same thing or something crazy complicated to return something to you. OOP works much better in teams and is a bit/lot of overhead when you are making contracts with yourself. However if I'm working with someone and they tell me call this to get a name then ill do that, if later they realize they need to…

I agree with you, for APIs - or very large teams where you can't communicate in person easily.

(And that's where C#'s way of dealing with getters and setters is a big win, because they look like member variables, so there's no extra kludginess.)

Re: Why you shouldn't use getters and setters on Android

#13
post #4

So, calling a "getter" method is slower (x1.5 to x2) than directly accessing a private field. Nothing new here: everyone with a fair understanding of how computers work should know that calling a [virtual] function is a more complex operation than accessing a field, hence it takes more time to complete. It's actually reassuring to know that it's only x1.5 to x2 slower, so thanks to the OP for figuring that. However t…

I've never found this argument very convincing. By adding the methods "string get_Name()" and "void set_Name(string name)" you are making _exactly_ the same contract as if you have "public string Name". There is no extra dependency here - the dependencies are identical.

Not at all.

Suppose you need a stapler for some work. You don't have one, but you know a colleague who does and who is willing to happily share it with you. You could go to her office, open the second drawer in her desk, take the stapler and leave. Or you could just ask her to give it to you. In both case the result is the same: you will get the stapler.

But there is a major difference : in the first case, you had to know where the stapler was. Your colleague knows it - it's her desk, after all - but because you decide to ignore the service she can provide and do it yourself, you have to know it as well. That means that you are both dependent of the manner of accessing the stapler.

What if someday she decides to move the stapler into the third drawer ? Because of this dependency, you would have to be informed of this change and start behaving accordingly. Your implementation would be impacted by a change in her implementation. And this is bad.

On the contrary, if you just asked her to give you the stapler, it wouldn't matter at all where it's stored. As the owner of this item she would the sole responsible for its location, and your behavior would never be impacted.

This is the purpose of encapsulation: preventing objects implementations from being impacted by changes in other objets implementations. You should be applying this everywhere, every times. Even for such small services as "give me that value, please". In your example, you should not need to know if a field or anything else is used to store the value because it's an implementation concern. You should just ask the value to the object.

Post reply on HN