Why you shouldn't use getters and setters on Android
blog.leocad.io
blog.leocad.io
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.
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.
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 :)
(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.)
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.
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.
Then again since you're some random guy....
I'd be willing to bet the percentage of time spent in getters and setters on the call stack is pretty insignificant.
Whilst it might not have a big impact, if every programmer thought pragmatically about energy usage then the environment as a whole would benefit.