Gotcha #80: Get/Set Interfaces

In an abstract data type, all member data should be private. However, a class that's just a collection of private data members with public get/set functions for access is not much of an abstract data type.

Recall that the purpose of data abstraction is to raise the level of discourse above a particular implementation of a type and enable readers and writers of code to communicate directly in the language of the problem domain. To accomplish this, an abstract data type is defined purely as a set of operations, and those operations correspond to our abstract view of what the type is. Consider a stack:

template <class T> 


class UnusableStack {


 public:


   UnusableStack();


   ~UnusableStack();


   T *getStack();


   void setStack( T * );


   int getTop();


   void setTop( int );


 private:


   T *s_;


   int top_;


};

The only positive thing one can say about this template is that it's properly named. There is no abstraction here, just a thinly disguised collection of data. The public interface doesn't provide an effective abstraction of a stack for the users of the type and doesn't even provide insulation against changes in the stack's implementation. A proper stack implementation provides a clear abstraction as well as implementation independence:

template <class T> 


class Stack {


 public:


   Stack();


   ~Stack();


   void push( const T & );


   T &top();


   void pop();


   bool empty() const;


 private:


   T *s_;


   int top_;


};

Now, in point of fact, no designer would actually produce a stack interface as flawed as that of UnusableStack. Every competent programmer knows what operations are required of a stack, and production of an effective interface is almost automatic. This is not the case for all abstract data types, however, particularly in the case where we're designing in domains where we're not domain experts. In these situations, it's essential to work closely with domain experts to determine not only what abstract data types are required but also what their operations should be. One of the surest ways to identify a project with inadequate domain expertise is by the large percentage of classes with get/set interfaces.

That said, it's often the case that some portion of a class's interface may properly consist of accessor, or get/set, functions. What is the proper form for rendering these functions? We have several common possibilities:

class C { 


 public:


   int getValue1() const            // get/set style 1


       { return value_; }


   void setValue1( int value )


       { value_ = value; }


   int &value2()             // get/set style 2


       { return value_; }


   int setValue3( int value ) // get/set style 3


       { return value_ = value; }


   int value4( int value ) { // get/set style 4


       int old = value_;


       value_ = value;


       return old;


   }


 private:


   int value_;


};

The second style is the tersest and most flexible but also the most dangerous. In returning a handle to the private implementation of the class, the value2 function is hardly an improvement over public data. Users of the class can develop dependencies on the current implementation and access the internals of the class directly. This form is problematic even if only read access is provided. Consider a class implemented with a standard library container:

class Users { 


 public:


   const std::map<std::string,User> &getUserContainer() const


       { return users_; }


   // . . .


 private:


   std::map<std::string,User> users_;


};

The "get" function has exposed the rather private information that the user container is implemented with a standard map. Any code that calls that public function now can (and most probably will) develop a dependency on that particular implementation of Users. In the likely case that profiling reveals a vector to be a more efficient implementation, all users of the Users class will have to be rewritten. This kind of accessor function should simply not exist.

The third style is a bit unusual, in that it doesn't actually provide access to the current value of the data member but both sets and returns the newly set value. (You're supposed to remember the old value. After all, you set it, right? No?) This allows users of the class to write expressions like a += setValue3(12) rather than the two short statements setValue1(12); a +=getValue1();. The real problem is that many users of the interface will assume that the value returned is the previous value, which can lead to some difficult-to-locate bugs.

Our fourth alternative is attractive in that it provides the ability to both get the current value and to set a new value with a single function. However, just getting the current value requires a little finesse:

int current = c.value4( 0 ); // get and set 


c.value4( current ); // restore

To get the current value, we must provide a "dummy" new value to value4. This bogus new value must then be reset to the previous value. This may seem a little loopy, but the technique does have a distinguished C++ pedigree and is used by the standard library facilities set_new_handler, set_unexpected, and set_terminate to register callback functions for memory management and exception handling. Typically, these functions are used to implement a stack discipline of callback functions without employing a stack specifically:

typedef void (*new_handler)(); // the type of a callback 


// . . .


new_handler old_handler = set_new_handler( handler ); // push


// do something . . .


set_new_handler( old_handler ); // pop

Using this mechanism to access the current handler can be involved. The following usage is a C++ coding idiom for doing so:

new_handler handler = set_new_handler( 0 ); // get current 


set_new_handler( handler ); // restore

However, outside its use in setting standard callbacks, avoid this approach as a general get/set mechanism. It raises the cost and complexity of simple read access to a data member, complicates exception safety and multithreaded code, and may be confused with get/set style number 3, described earlier.

The first get/set style is the preferred one. It's the simplest available mechanism, it's efficient, and, most important, it's unambiguous to all readers of the code:

int a = c.getValue1(); // get, of course 


c.setValue1( 12 ); // set, of course

If your class design must include get/set access, use style number 1.