4 ms·

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 comput

by jpatte 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.)
- jpatte 13y ago
  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.

by jpatte 13y ago

AndrewDucker 13y ago

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 13y ago
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 13y ago
  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.)
jpatte 13y ago
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.