What good are public variables then?

Question

I\'m a total newbie with tons of ?\'s in my mind and a lot to experience with C++ yet! There\'s been something which I find really confusing and it\'s the use of public vari

Answer 1

As Scott Meyers says on Effective C++ book: Avoid data members in the public interface. Why? because it's more easy to code (everything is a member function), also you have more control on the access of that variable, and what Doug T. and the others said about functional abstraction.

If you don't need a class (like in your example) you have the choice of use a struct...

Look this post written by Scott if you don't have the book :)

Answer 2

By hiding the variable and adding methods now, the class designer allows for inserting arbitrary code into those methods in the future without breaking tons of code that use the attributes directly.

Also note that providing a lot of accessor/mutator methods is generally a sign that your class design needs another look for possible improvement. Class methods should implement actual logic, not just provide access to each member.

I use public variables only in struct form. For example, I might have a database table that represents a string->value mapping, where value is a composite data structure. I'd just write a structure and use for example std::map<std::string, MyStruct> to represent the database table. I don't need to actually do work on the data, merely be able to look it up and make use of it when required.

As noted in a couple comments, even structs can often benefit from judicial use of methods, for example a couple of common constructors to keep the members sanely initialized, a clear function to reuse the structure, etc.

Answer 3

I know in Java we use public variables, in fact,

public static final

variables as means to specify constants before enumeration was introduced.

For example,

class Direction
{

public static final String NORTH = "north";
...
}

It has been a while I looked into C++, so not sure if there are enumerated types available. You can use the similar code above if enumeration is not available in C++

Answer 4

I agree, in part, with the other answers regarding the use of getter and setter methods to allow for future changes but there is still a fundamental problem, you are exposing the internal data of your object for other objects to modify.

It is better to ask the object to perform some action on the data it holds, via a method, rather than treat the object as a collection of values.

Here's an interesting article on Why Getter and Setter Methods are Evil, it's written with Java in mind but the same applies to C++.

Answer 5

Anything exposed as public becomes part of the contract of that object. If you expose data publicly then it must continue to behave properly when the data values are changed. For struct type objects this may well be appropriate.

Having a high number of getters and setters can be a warning sign that the object is really a struct and it may be better to expose the fields directly. However, I have implemented struct type objects in order to allow fields to have multiple names. Fields could have multiple setters or getters as required allowing name translation between different domains. The real fields had descriptive names. Additional getters and setters used the domain specific codes for those fields.

As other have noted, getters and setters are indicative of the presence of a field. There is no requirement that such a field exist, only that its behavior exists. Making the getters and setters public implies there is a reason for the public to be able to modify or read the value of that field. Think twice about the purpose, and you may change the method name or not make it public.

Answer 6

I don't care much for writing accessors that do nothing. I have two reasons for this attitude.

• One of the reasons for doing so is that the code will later be inherited from. I've found this is usually not true in practice. What usually happens is the code is refactored or replaced. The lifespan of code is almost always very short.

• You're making extra work now for something that might, or might not, happen in the future. This is a variation of the "premature optimization" fault.

There are places where it's a good idea and places where it's not. In most cases I feel the answer is it's not useful.