CODEWITHSUNDEEP
c++
stanigator
stanigator

Reputation: 10944

practices on when to implement accessors on private member variables rather than making them public

I know the differences between public member variables and accessors on private member variables, and saw a few posts already on stack overflow about this. My question has more to do with practices though. Other than not breaking class invariants, what would usually be criterias in terms of practicality to make the member variables to be public rather than private with accessors, and vice versa? Thanks in advance for the advices.

Upvotes: 2

Views: 669

Answers (8)

JohnMcG
JohnMcG

Reputation: 8815

Make your data private in your class whenever it would be possible for an object of your class to be screwed up if a client changed that data, or you don't want clients dependent on your implementation of the class.

Which translates to "almost always."

Upvotes: 1

Pieter
Pieter

Reputation: 17715

While most answers focus on the design / encapsulation standpoint (and I agree to the general consensus, "why not use setter / getter?"). I'd like to add that once you've hunted for a bug in some large legacy code bases, with public members, you'll never, ever, EVER, write a class without setter / getters.

Imagine the following: you have a large codebase (talking over 1M+ lines of code), where a lot of highly optimized legacy code passes pointers around, does bit twiddling etc. etc.

Now, after hours of debugging, you found that a certain member is in an inconsistent state, you're wondering "hmm, this causes the bug, now how did this member get that value..."

1) setter/getters: you put a breakpoint, 5 minutes later, bug is solved

2) public member: you're in for hours and hours of annoying detective work

Public members: don't do it, no gain, only potential pain

Upvotes: 0

Niki Yoshiuchi
Niki Yoshiuchi

Reputation: 17591

I think there are two important questions to ask about your data to make that decision: 1) is the data bounded by certain ranges of values? and 2) does the class depend on the consistency of the state of the data from one operation to another? If you answer "yes" to either of those questions than you had better use accessors and mutators.

For example, let's say you have a class representing a point in 2D space. If you can set that point to any arbitrary location then there is no reason to make that data private. But now lets say that the points have to be on a graph from [-100,-100] to [100,100]. In that case you would want to limit the values that the point can be assigned to (case 1).

Another example (this one is a little contrived): you have a class that represents a priority queue and you are storing the minimum value in a variable. If you change the value of that variable then it may no longer be the minimum value in which case you need to re-order the heap. Since the state of the heap depends on the value of that variable, you need to limit its access (either but not allowing it to be modified, or when it is modified re-ordering the heap as necessary).

Upvotes: 1

Remus Rusanu
Remus Rusanu

Reputation: 294407

Using an accessor will enforce the client to treat the members as functions, not as raw memory. For instance it will not allow taking the address of said member. So even if the member is as POD as a simple int I still use a get-set pair of function for it. This pays of in the long run as refactoring can change the implementation w/o surprises like 'oh wait, I was taking a void* to your member'.

Performance wise all compiler will inline this set/get accessors and the assembly will look just as if referencing a public member field.

I don't think in the past 5 years I ever wrote a class that exposed its members public.

Upvotes: 4

beef2k
beef2k

Reputation: 2257

My rule of thumb is: If it's not a really simple structure (e.g. Point and Complex) implement it as accessors to private member variables. And if you are not sure if your structure is simple enough, it probably isn't ;) ..

This way, you always have the option to extend the logic of setting/getting the variable without breaking existing code. Yes, it might be a little more work to implement the accessors in the first place, but it's much much much more work to modify the code to accessors if it was a direct variable access before.

Upvotes: 7

Zifre
Zifre

Reputation: 27008

The only time to use public member variables is when the class is just a "bag of bits". This means there is absolutely no chance that you will ever have to add an invariant. In that case, you should probably use a struct.

Upvotes: 3

Andrew Hare
Andrew Hare

Reputation: 351638

This is a matter of encapsulation. You generally do not want to expose member variables to the caller as then you lose significant control over the state of the object. Classes with strong, simple interfaces and no exposed fields are easier to maintain, debug, and scale.

Upvotes: 1

Charlie Martin
Charlie Martin

Reputation: 112404

Always. Never make a member variable public. There is no advantage to it: you can always make your get and set methods inline.

Upvotes: 2

Related Questions