Is it good practice to create functions to access class variables?

Question

As the title says: Is it good practice to create functions to access class variables?

I have seen quite a number of pieces of code that do something like the following:

class MyClass {
public:
void setx(int a);
void sety(int b);
int read_x;
int read_y;

private:
int x;
int y;

};

void MyClass::setx(int a) {
x=a;
}

void MyClass::sety(int b) {
y = b;
}

int MyClass::read_x() {
return x;
{

int MyClass::read_y() {
return y;
}

So rather than accessing variables directly(MyClass.x) they use functions to read and set the variable values etc.

Is this a standard or good practice?

score 4 · Accepted Answer · edited May 23 '17 at 11:48

4

Yes, accessor functions are preffered to direct member access for several reasons. They provide a unique access point, are easier to track and to debug.

For example, instead of setting a breakpoint everywhere in the code where MyClass.x is changed, you can just set a single breakpoint in MyClass::setX().

However, although better than direct member access, accessor methods are not without their drawbacks, if misused. For details, you can visit Getters and Setters are bad OO design?

edited May 23 '17 at 11:48

Community

1
1

answered Mar 12 '12 at 23:46

Luchian Grigore

253,575
64
457
625

1

Yup, accessors also decrease coupling between the interface (public methods) and the implementation (private fields). – Frédéric Hamidi Mar 12 '12 at 23:49
With one exception (IMO): If you have a variable that you know is never going to need a guard and it is a simple type then go ahead and just make it public. Adding functions to get/set it is just code bloat. – Ed S. Mar 12 '12 at 23:49
@EdS.: Just for consistency, I'd add a simple accessor that returns a non-`const` ref, so the access remains the same. – Xeo Mar 12 '12 at 23:53
I'm hesitant to agree. "Knowing you are NEVER going to need a guard." Heyre be dragons. – Michael Wilson Mar 13 '12 at 00:25
@Xeo: I'd be inclined to stay far away of adding mutating methods for consistency. If there's a definite need, then absolutely (though I'd argue that such a 'need' frequently highlights a design issue.) But the fewer things that are modifying data the better IMHO. – Michael Wilson Mar 13 '12 at 00:27
@Michael: If the member is going to be public anyways? – Xeo Mar 13 '12 at 00:30
@Xeo I think making the member public is pretty much the same issue. It necessitates external dependency on the implementation of the class, rather than the intended interface. If something external to the class needs to both access and modify a member variable within another object in a simple way, why is it in that object? I'm definitely not so dogmatic as to say never. For instance, if you're using classes as intermediate data types for de/serialization (the "class as struct" usage) then yeah, I'd say it's arguably ok. – Michael Wilson Mar 13 '12 at 16:20

score 2 · Answer 2 · answered Mar 12 '12 at 23:54

Rather than access variables directly? Absolutely. Creating a programmatic interface layer decouples you from the implementation details of those internal variables themselves. You then afford yourself additional flexibility for things like creating mocked-out implementations of the class in question (for testing), creating proxy classes (for decorated functionality like logging, etc.)

I'd warn against automatically creating them for everything where you may not need them. But that's a different issue.

Much like working out at the gym: It gives back more than it takes ;)

score 1 · Answer 3 · answered Mar 12 '12 at 23:49

Yes they are ok, however I would also say that you should keep your classes small than you would with say Java and what not so you don't end up with types that are mostly getters and setters.

Typically a class holds a (ideally single) state (which can be got if needed) and has an implementation which should ideally remain private.

score 1 · Answer 4 · answered Mar 12 '12 at 23:56

1

This is important as it separates the interface of the class from the underlying data model. You often see basic code like the example you posted, and at first, a lot of it can seem like an unnecessary complication. However, it provides a (self documenting) framework where the implmentation of the object can be changed without breaking code that accesses the objects of the class via the defined interface.

answered Mar 12 '12 at 23:56

learnvst

15,455
16
74
121

Absolutely. It's tough to explain how important it is until you find yourself having not done it for a few thousand lines ;) – Michael Wilson Mar 13 '12 at 00:28

Is it good practice to create functions to access class variables?

4 Answers4