Calling this->get/this->set methods versus directly accesing member variables in C++

Question

Suppose I have a class Foo, with a private variable bar_ containing some state for Foo. If necessary, I may write public get/set methods for bar_. Naturally, I avoid this as much as possible to maintain encapsulation.

Assuming I have these get/set methods, whenever I have to access or modify bar_ within a method belonging to Foo, I usually do it directly to bar_, instead of using the get/set methods, which I use for accessing bar_ from outside the class. I have no justification other than concerns regarding the speed of directly accessing the variable versus calling the methods, but I suspect that if the get/set methods are defined inline (which they are) it shouldn't make a difference. Does it make a difference? Does constness play a role in this?

So far I haven't had any problems with this, but I have a lingering feeling I am Doing It Wrong. Are there any compelling arguments for not doing it? Any guidelines regarding this?

Answer 1

I have no justification other than concerns regarding the speed of directly accessing the variable versus calling the methods, but I suspect that if the get/set methods are defined inline (which they are) it shouldn't make a difference. Does it make a difference? Does constness play a role in this?

The inline keyword hardly plays a role in whether or not the compiler does any inlining. The use for the keyword in that regard is essentially deprecated. Modern compilers inline like crazy, and they know when to do it better tan any programmer does.

Any compiler worth dirt will say "Hm, call this function to get this member variable; hey I can just get the member variable!" You're worrying about nothing. This happens regardless of any inline keywords.

That said, I almost always use the member functions. If I change how a variable behaves when it's accessed, I now "automatically" apply that everywhere it's used. Clean code should be your goal, though, not a dogmatic "always skip functions" or not.

Anytime I just want a variable value, I use the corresponding member variable. (i.e, if I were writing std::vector, if I needed to check if the size was less than something, I'd say size() < x). But if it's cleaner to use the variable directly, do that instead, such as mSize++.

const-ness is irrelevant. If you're in a non-const function, you'll use the non-const version of your getter, same with const. Obviously, using the members directly maintains const-ness. There is no difference.

Answer 2

If your compiler does any inlining at all, it will be able to inline get and set methods defined and used within a given class. const has no bearing on this, and the inline directive doesn't make much difference either.

I generally prefer to use my get() and set() methods even from within the class definition, when I can. You get all the same benefits that you get by using them outside the class definition, and there is no speed penalty.

Answer 3

It's better to use the get and set methods: It's cleaner, upholds DRY principles better (only do validation once), and allows subclasses to override the methods and see consistent behavior on all changes to the variable.

Answer 4

There is no rule that fits every situation in my opinion. Sometimes, it is better to write these private set/get functions, sometimes it is not.

For example, if all what get/set functions do is this:

void set(int n)
{
   member_n = n;
}
int get_n() const
{
  return member_n;
}

Then, there is no need actually for these functions!

In other situations, where you need to normalize a value for example, you could write those get/set functions. e.g. to normalize an angle:

void setAngle(int angle)
{
  member_angle = angle%two_PI;
}

Answer 5

This is a matter of opinion, and a matter of judgement, but in general the interior of your Foo methods are within the encapsulation you're trying to maintain, and so it is entirely reasonable for them to access bar_ directly. They are all in the same location, and so if you change the interior representation of your class to remove bar_, you can easily find all of the uses to change as well.

There are justifications for using get/set functions internally in large classes, especially where bar_ is something that's not a key piece of the class's implementation design and could conceivably be changed without affecting the rest of it much. However, in many cases if you are changing the internal representation in such a way that bar_ no longer exists and its corresponding get_bar() is computed, you will almost certainly want to revisit the internal usage to determine whether you want to refactor it so that it doesn't do that computation or does it differently.

With that said, speed is not a justification for not doing it -- but the comprehensibility cost of too many layers of encapsulation are; a forty-line class should not be complicated with additional internal encapsulation unless it's one of the cases where the encapsulation actually simplifies the code.

Edit: Also, ehdv raises an important issue that I missed: If you anticipate derived classes that override this piece of the internal representation, using get/set functions can make that overriding easier to do consistently. So that can be another factor in the decision.

Answer 6

get/set should only be necessary when there is some sort of invariant, precondition or postcondition that must be upheld by the class. If the modification of the value doesn't have a 'ripple effect' throughout the rest of the class then the user should be able to modify it directly. However if changing the value will cause something else to happen (e.g., changing a cache size might cause cached items to be purged) then get/set is appropriate.

Answer 7

I know it is close to herecy, but I hate get/set methods. Loathe them. Almost never write them.

Generally, a class should either provide much more high-level operations than directly and simply reading and modifying internal state variables, or it should get the hell out of the way and act like the struct it is.

Even if I were to write one, I would almost never use it inside the class. The whole point of them is that you can change the internal representation of thing without affecting a client. Inside the class, it is the internal representation you care about! If you are tempted to do a lot of operations on the class using its own interface inside the class, you probably have a second class in there fighting to get out.