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 metho

Answer 1

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

Answer 2

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 3

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 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

I prefer to use get/set function. Because I found that it is very hard to debug if use member variable directly. Especially when you have a big class and there are a lot functions access bar_.

Answer 6

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.