
Why you shouldn't use getters and setters on Android - luu
http://blog.leocad.io/post/why-you-shouldnt-use-getters-and-setters-on-android
======
jpatte
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 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.

~~~
AndrewDucker
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.

~~~
mechinn
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 :)

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

------
supermatt
And why use a RNG, when you can just return 3?
[http://xkcd.com/221/](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.

~~~
simonh
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....

------
Superleroy
You 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...](http://developer.android.com/training/articles/perf-tips.html)

------
visural
While 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.

~~~
nextw33k
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.

~~~
lesiki
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.

