which style of member-access is preferable [duplicate]

Question

the purpose of oop using classes is to encapsulate members from the outer space. i always read that accessing members should be done by methods. for example:

template<typename T>
class foo_1 {
  T state_;
public:
  // following below
};

the most common doing that by my professor was to have a get and set method.

  // variant 1
  T const& getState() { return state_; }
  void setState(T const& v) { state_ = v; }

or like this:

  // variant 2
  // in my opinion it is easier to read
  T const& state() { return state_; }
  void state(T const& v) { state_ = v; }

assume the state_ is a variable, which is checked periodically and there is no need to ensure the value (state) is consistent. Is there any disadvantage of accessing the state by reference? for example:

  // variant 3
  // do it by reference
  T& state() { return state_; }

or even directly, if I declare the variable as public.

template<typename T>
class foo {
public:
  // variant 4
  T state;
};

In variant 4 I could even ensure consistence by using c++11 atomic.

So my question is, which one should I prefer?, Is there any coding standard which would decline one of these pattern?

for some code see here

Answer 1

Instead of chasing guidelines for implementation nuances I suggest to look for the root motivation to have the setters and getter in the first place.

Once you understand how they help, what are the cases where there is practical difference between the forms and how it manifests, you probably can answer your question for good.

And from that point see why chasing guidelines instead of just writing the particular code to a sensible form is a bad idea.

Also if you start writing actually OO code instead of the usual faked structs related to the 'anaemic model' antipattern, you will see that a setter is an extremely rare beast, and even raw getters are not so common.

Answer 2

I don't see any strong grounds for choosing between 1 & 2 (although the getter should be const-qualified) - just choose a style and stick with it (or follow the style of your existing code base).

In variant 3, you're still hiding some information. For example, you could change to

template<typename T>
class foo {
  std::unique_ptr<T> state_;
public:
  foo() : state_(new T()) {}
  T& state() { return *state_; }
  T const& state() const { return *state_; }
};

without affecting your callers. So, it may still be useful. You lose the option to add validation (or logging, or breakpoints, or ...) to the setter later if you need it, at least without changing your client code too, so be aware you have lost some flexibility in exchange for a little less typing.

Variant 4 is also perfectly reasonable: for example, there may be no reason to restrict access to some POD aggregates. Note that a class with only public members is just a struct, so you might as well call it one. However, now you definitely can't change any detail without also changing the client. So, this aggregate type is just a convenient bundle of data but doesn't reduce coupling at all.

Answer 3

None of the above.

Properties on classes is an anti-pattern. Sure, you've heard somewhere that accessing members directly is a bad thing, so you to wrap them in a method or two to access them indirectly.. but think for a moment what you've just done - nothing of any real substance.

The trouble starts when you need to modify any of them, the concept of wrapping the property in a method so you can change the underlying type is just plain wrong. You can do this if you wrap the properties in a real method but not if you have a stupid method that pretends to be the member directly (ie a property).

eg. See this blog post for an example.

the point is that, if you have internal state, you should never allow access to that state in terms of the state itself. You need to always think of accessing the object as a whole.

Too often languages and standards (and IDE helper autocompletions) say you must wrap member access in a property method, they're wrong. You should never even think of the members as something to access, directly or indirectly, from outside the class. Think of the class and think what kind of interface it should support to provide its functionality to clients.