Why you shouldn't use getters and setters on Android
blog.leocad.io
Why you shouldn't use getters and setters on Android
1–10 of 13 posts
Re: Why you shouldn't use getters and setters on Android
#2You could have skipped the Benchmarks, the official Documentatcion already said that you should not use internal getters/setters because of the bad performance.
http://developer.android.com/training/articles/perf-tips.htm...
Re: Why you shouldn't use getters and setters on Android
#3And why use a RNG, when you can just return 3? http://xkcd.com/221/
The reason to use accessors is encapsulation. If the public field is private to your package/application then by all means access it directly, but if you are exposing it publicly then expect your application to be broken by third parties.
By providing accessors, you are communicating to a developer a strict mechanism for interacting with your library/application.
What if myString (in your example) needed to have bounds or be formatted in a specific way (validation)? What if it does in the future?
Without strict application flow control enforced by accessors (i.e. allowing your objects fields to be hijacked at any time, from anywhere), you cannot be sure that your application will be consistent.
Re: Why you shouldn't use getters and setters on Android
#4So, 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 that still doesn't make it a valid argument to discard accessors entirely. Getters and setters play an important role in a critical principle of OOP, which is object encapsulation. They form the boundary between and object contract (or interface) and its implementation.
Every time you write code that directly accesses an object's field, you introduce a new dependency to how this object was implemented - and this is bad, because you should always depend on what it does, not how it does it.
And this is also true for plain "data objects" : they are objects, they provide data. You need to know what data they can provide; you shouldn't care about how they provide it. Leave that to the guy who write these objects' classes - and if it was you, learn to be schizophrenic.
Dependency to implementation just make maintenance operations harder, which IMHO is a lot more evil than losing a bit of performance. It's a trade-off I can accept easily, especially since computers and devices still get more powerful and most applications just don't require that much power to run smoothly - and if it does, you should optimize your code structure and algorithms instead of looking for micro-optimizations like that.
Re: Why you shouldn't use getters and setters on Android
#5While the benchmark shows that there is a measurable difference between using getters/setters and NOT using them. I have doubts this would make a great deal of difference in application level code. The performance bottlenecks are most likely going to be IO or calls, or if the app is CPU bound, actual calculation code.
I'd be willing to bet the percentage of time spent in getters and setters on the call stack is pretty insignificant.
Re: Why you shouldn't use getters and setters on Android
#6[deleted]
Re: Why you shouldn't use getters and setters on Android
#7And why use a RNG, when you can just return 3? http://xkcd.com/221/ The reason to use accessors is encapsulation. If the public field is private to your package/application then by all means access it directly, but if you are exposing it publicly then expect your application to be broken by third parties. By providing accessors, you are communicating to a developer a strict mechanism for interacting with your library…
But how do we know that the 3 is random? Maybe you have some hidden three-ist agenda? I'm much more inclined to trust Randal on something like this than some random guy on Hacker News!
Then again since you're some random guy....
Re: Why you shouldn't use getters and setters on Android
#8While the benchmark shows that there is a measurable difference between using getters/setters and NOT using them. I have doubts this would make a great deal of difference in application level code. The performance bottlenecks are most likely going to be IO or calls, or if the app is CPU bound, actual calculation code. I'd be willing to bet the percentage of time spent in getters and setters on the call stack is prett…
That is a very desktop application view. As programmers we should consider CPU cycles equating to battery life.
Whilst it might not have a big impact, if every programmer thought pragmatically about energy usage then the environment as a whole would benefit.
Re: Why you shouldn't use getters and setters on Android
#9So, 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.
Re: Why you shouldn't use getters and setters on Android
#10While the benchmark shows that there is a measurable difference between using getters/setters and NOT using them. I have doubts this would make a great deal of difference in application level code. The performance bottlenecks are most likely going to be IO or calls, or if the app is CPU bound, actual calculation code. I'd be willing to bet the percentage of time spent in getters and setters on the call stack is prett…
That is a very desktop application view. As programmers we should consider CPU cycles equating to battery life. Whilst it might not have a big impact, if every programmer thought pragmatically about energy usage then the environment as a whole would benefit.
I think the point is that whatever slowdown the use of Accessor pattern introduces will actually be a lot smaller than 2X, which is useful information when deciding whether to discard the great benefits of using the Accessor pattern that others have mentioned.