Getting Abstractions

Herb Sutter (http://www.gotw.ca/) is convener of the ISO C++ Standards committee, author of Exceptional C++ and More Exceptional C++, and Visual C++ architect for Microsoft.

Jim Hyslop is a senior software designer for Leitch Technology International. He can be reached at jhyslopieee.org.

Iwas walking a little too near Bob's part of the office. "Hey Junior, there you are! Got a sec?" I tensed and thought fast, but it was too late to pretend I hadn't heard him. No escape; he had me.

"Sure, Bob," I said. "What's up?"

"I've started using that new GUI control you guys produced last week," he said, gesturing with his latte cup. The drink slopped slightly, but he ignored the small streams that ran over his fingers. "Great job on that thing. I love it. It's perfect. You dudes really rock, man."

"Thanks." Now I was getting worried. Praise from Bob?

"It's perfect," he repeated, "and now you just need to add a few tweaks. For usability, that is."

"Oh, sure. Well, that sounds reasonable," I replied agreeably. "What do you have in mind?"

"I need to be able to change the control's style and stuff, and it's too hard to do it now. The stuff I need is mostly already in there, it's just private and you need to make it public so people can get at it. That's all."

"Public? You don't mean the data members, do you?"

"What's wrong with public data? Ha, public data is fine, and it's underrated," Bob laughed, then paused to slurp his latte. "It's saved me lots of coding time."

I frowned. "How?"

"Because when I need to change the object I didn't have to waste a lot of effort going through functions that probably do more than I need or aren't quite what I want. Come here, Junior, I'll show you an example." I walked closer and watched as he brought up my code. Simplified, it boiled down to this:

//--- file customcontrol.h ---
//
class CustomControl : public Control {
public:
  // ... public stuff ...
private:
  Font f;
  Color c;
  // ... more stuff ...
};

Bob pointed to the f and c members. "I need to be able to change those. You didn't provide functions to change the control's Font and Color, and actually you don't have to, you just have to make these public so I can set them." I must have had a priceless expression on my face because he impatiently added: "Don't give me that look, I already know it works fine because I tried it."

"Uh, tried it?" I managed.

"Sure. See?" And he pulled up a file that used my control, and I saw:

#define private public
  #include "customcontrol.h"
#undef private

"I set the Font and Color myself and it works just fine—now your control's perfect for what I need..."

class CustomControl : public Control {
public:
  const Color& GetColor();
  void SetColor( Color& );

  const Font& GetFont();
  void SetFont( Font& );

  // ... other public stuff ...

private:
  Font f;
  Color c;
  // ... more stuff ...
};

"This is one obvious approach. Daughter: Why is this better than a public member variable?" Now she was looking at Wendy.

"Er, ah..." Wendy was caught slightly off guard, and tried to think fast. "Well, because it's not a public member variable?"

The Guru smiled. I think she might almost have laughed. "Quite true, but pray be specific."

"Er, it's a function, and so the CustomControl object knows when it's being changed and has a chance to control the change or do something in response. Oh yeah, I see...Bob had to throw in calls to Refresh() or Redraw() manually to kick the object so it would know it had to do something, because otherwise it didn't know about his changes to Font and Color. But this way you don't need to do that, because the object can do the right things when you call SetFont() or SetColor(). Right?"

"Good. And?"

"Uh, functions can be made safe for versioning...right, maybe today I have a Font data member and a Color data member, but tomorrow maybe I'll remove them and then the code that uses the CustomControl just needs to recompile, it doesn't need to change. If the code used the data members directly, it would break if I ever removed or renamed the data members. How's that?"

"Indeed. Other specific reasons why functions are superior to data are that they can be made virtual, can insulate themselves against some misuses, can perform precondition and postcondition checking, and so forth."

I put up my hand.

"Yes?" the Guru asked.

"But aren't getters and setters bad? I mean, everyone knows they're bad."

"Take care about what 'everyone knows,'" the Guru cautioned. "There was a time when everyone knew the world was flat. What specifically is bad about getters and setters?"

"Well, they're not an abstraction."

"Nonsense," the Guru said definitely. "They are frequently overused instead of providing a more appropriate abstraction, that is true. Getters and setters are better than public member variables, and they are worse than a better abstraction if a more appropriate and high-level one exists. But getters and setters can nevertheless be a good abstraction. In particular, here the Color and Font getters and setters do provide an abstraction, albeit at this point a thin one. There need not be an exact corresponding backing store—the Color and Font getters and setters allow changing these attributes of the object with the consent and active support of the object itself, regardless of whether the object has a Color or Font data member inside it."

"Oh. But isn't there a simpler way to write the getters and setters by overloading them?" I picked up the whiteboard marker and wrote:

class CustomControl : public Control {
public:
  const Color& Color();
  void Color( Color& );

  const Font& Font();
  void Font( Font& );

  // ... other stuff ...
};

The Guru shrugged. "This is simply another way. It is not an abomination."

So," Wendy said mischievously, "do you 'get' the abstraction?"

Kerry and I groaned, and pelted her with paper clips.

The Guru turned to leave. "I have not much hope that Bob can be cured before he is fired," the words wafted back over her shoulder, "but there is a chance of it. My heart tells me that he has some part to play yet, for good or ill, before the end..."

References

[1] For more on the history of why protected data was originally permitted and why even the person who campaigned for it now agrees it was a bad idea, see B. Stroustrup, The Design and Evolution of C++ (Addison-Wesley, 1994).