Software Development

The only counter argument I've heard is that you don't want users messing with the internals so you use private and possibly protected interfaces. My objections to the private keyword are as follows. If you use private, don't let anyone derive your classes. If you want someone to alter the behaviour of your classes, then they need access to the internal data. You can't have it both ways. You need to make certain that when you release classes that can be derived that they don't change in the future. IOW, you can't tell someone that they may modify the behaviour of your car and at the same time say that can't look under the hood to change the engine in order to make it go faster for example. Just doesn't make sense.

Here's a simple situation. Suppose you find a bug in your code. Now suppose I tell you that you have to fix it without having access to the internals of your class. You must fix the bug by deriving the class and using this derived class as the new implementation for your interface. Could you do it? My bet is not likely. Except for really simple classes, there's just no way you can fix the bug. Fixing a bug is altering the behaviour of a class. Sure, it's not an extension of what's already there. But now I tell you that I lied about the bug. The bug wasn't a bug at all. It was working perfectly, only that the client wants a slightly different behaviour. What I really asked you was to implement a new method that extended the functionality of the existing class. But you can't implement the new method because it's the exact same problem as fixing a bug.

Ok, with the background out of the way why I don't like the private keyword, back to the actual topic I want to discuss. This has to do with protected interfaces.

Having said that the protected keyword can get us around the problem of updating internal data with the caveat that changes of the internals will break derived classes, we look at a particular case where even protected will not help you.

People who advocate the private keyword often support the idea of protected interfaces for use by derived classes. This keeps encapsulation intact and allows additional methods to be used only by derived classes to extend the behaviour of the base classes. Sounds nice in theory and is ok much of the time if the instance only deals with itself and not other instances. Especially not other instances that have the same base class, but different derived class.

With the private keyword, you can alter the internal of ALL instances of that class. So if you have a method where another instance of the same class is passed along as a parameter, you can fiddle with the internals of this other object all you want.

X a,b;

a can alter the private members of b. And b can alter the private members of a. This is assuming that b is passed to a and vice versa.

Now comes in 'protected' and things don't work quite the same. Take the following example.

class Y
{
protected:
  vector<Y*> Containers;
  virtual void insert(node *n)=0;
public:
  virtual void insert(int t) 
  {
    node *n = new node(t);
    for(vector<Y*>::iterator i=Containers.begin();i!=Container.end();++i)
    {
      Y *y = *i;
      y->insert(n);
    }
  }
};

Basically this is a multilist where if you insert an integer in one list, it'll get inserted in all lists found in the Containers vector. The above code will work fine. It uses the basic principle of separation of concerns. insert(int t) is the public method that the tells all the containers to insert this value. But it can't call itself. Se another insert(node *n) is used for insertion into individual lists.

Everything works. We're happy and we move on.

Except for one thing. Class Y has no internal data. That's up to the derived classes.

class Y
{
protected:
  vector<Y*> Containers;
  virtual void insert(node *n)=0;
public:
  virtual void insert(int t) 
  {
    node *n = new node(t);
    for(vector<Y*>::iterator i=Containers.begin();i!=Container.end();++i)
    {
      Y *y = *i;
      y->insert(n);
    }
  }
};

class Z : public Y
{
protected:
  vector<node*> lst;
  void insert(node *n) {lst.push_back(n);}
};

So far so good. Class Z has its own internal list and everybody is happy. We can use as many objects of class Z or any other class that is derived from Y. This looks pretty good so far. For example, class S could derive from class Y and use a set instead of a vector. You could use any amount of instances from S and Z in this setup.

But what if insert(int t) was a pure virtual function? Or what if you decided to derive insert(int t) to update some internal data in your derived class?

Take a GOOD look at the code I listed above. Now compare it to the code below. You'll see that the code is nearly identical. The only difference is that I have moved the insert(int t) method from the base class to the derived class.

class Y
{
protected:
  vector<Y*> Containers;
  virtual void insert(node *n)=0;
public:
  virtual void insert(int t)=0;
};

class Z : public Y
{
protected:
  vector<node*> lst;
  void insert(node *n) {lst.push_back(n);}
public:
  void insert(int t) 
  {
    node *n = new node(t);
    for(vector<Y*>::iterator i=Containers.begin();i!=Container.end();++i)
    {
      Y *y = *i;
      y->insert(n);
    }
  }

};

One may argue about accessing the Containers list directly as it's not an interface. True enough. But the containers' list can be stored anywhere. It can be stored within the derived class upon instantiation or whatever else. That's not the issue. The issue is the protected interface with y->insert(n). It no longer works.

Derived classes are supposed to have access to protected members and methods of its base class. But only if the pointer or reference is identical to the type of the derived object.

Here's a list describing access to protected methods:

1. Code is in Y, pointer is Y, method called is in Y (OK)
2. Code is in Z, pointer is Z, method called is in Y (OK)
3. Code is in Z, pointer is Y, method called in is Y (NOT OK)

The third scenario will generate an access violation in the compiler. Won't let you do it.

What this means is that you cannot have a protected interface that can be shared amongst instances of different derived types. The IS-A relationship is effectively broken when dealing with base class references which means a good portion of polymorphism is out the window if you use protected interfaces.

Stated a different way, derived objects cannot invoke protected methods using base class references or pointers. This restriction applies to protected members as well. Polymorphism at the protected level only works if the invoking of virtual methods is done by the base class. Beyond that, polymorphism at the protected level is not available in any form to derived classes.

And that really puts one in an odd position with respect to protection levels. Protected interfaces are rather strange beasts. As long as you only use a reference with the same type as the derived object in question, you're fine. But use a base pointer and you lose access to the protected methods and members effectively killing polymorphism.

It's like climbing Mount Everest only to have it disappear once you reach the top. So while protected interfaces are useful in some cases, there are serious flaws that make them less than optimal. Protected members suffer from some of the same flaws, but you can't do polymorphism with data alone (or at all in standard C++ [my kingdom for properties!!!]). The issue of disappearing access is still there though. And although it doesn't come up often, it does happen.

So what I'm saying is that protected isn't that good of an option either though it'll do fine in most cases. Here are two examples where even using protected doesn't work.

The first case is my Project V GUI engine. I have a class called UIElement. I have a list of protected members for a wide range of things like position, caching, visible status, enabled status, active region, events, visual hierarchy, ZOrder, etc. If you derive a UIElement to create a custom component, you're all set to go as long as you only modify your own object's behaviour. So far, so good.

But the next step after a UIElement is a compound component called UIContainer. It contains many UIElements that may have been derived. So it can contain other UIContainers as well as things like UIImage, UIEditBox, etc. The problem is that when the container starts looking at the protected members of UIElement (when drawing on screen for example to figure what portions of the screen is obstructed or not), UIContainer no longer has access to those protected members even though it can access those same protected members within its own instance.

In this case, a protected interface would be of no use since I cannot access protected methods any more than I can access protected members. Anything derived from UIContainer would have identical problems with the UIContainer protected members to access the list of GUI sub elements. Luckily, I've never had to go beyond the public interface for sub elements.

The second example is my compound list that can be ordered multiple ways. The idea for the code examples I gave above stem from this compound list. You cannot create containers that use protected interfaces. And it's not just containers. Any time you want to use two instances together using polymorphism, you cannot do it with a protected interface. It's gotta be public. I was intending to do automatic conversion of iterators between the different lists. I do have a way of accomplishing this, but it won't be with a protected interface. So I'll do it with a public interface. The only thing an iterator needs is the current node. I'm gonna have the iterator have a virtual casting operator to the internal node itself. That way, you can convert iterators by simply constructing them from old iterators without having to know what type it is. You lose security for ease of use. If a protected interface worked, I'd just have the constructor retrieve the internal node from the passed iterator. Oh well.

One can argue about the examples and whatnot all day long, but they're just examples to show the issues at hand. At the end of the day, nothing will alter the fact that private and protected are insufficient to support proper inheritance, polymorphism and encapsulation in a way that is consistent and usable.

After re-reading this post, I find myself surprised that I wrote that last sentence. I originally wrote it as a response that followed from the flaws of the 'private' keyword and protected interfaces. Looking at it now, that statement goes well beyond those two specific things. I stand by it.

If there are some people that don't understand my position and think it's completely out in left field, rest assured that it isn't. Here's a link to the C++ FAQ lite for the question I've been told to never use protected data, and instead to always use private data with protected access functions. Is that a good rule?

Here's a portion of that answer.

Nope.

Whenever someone says to you, "You should always make data private," stop right there — it's an "always" or "never" rule, and those rules are what I call one-size-fits-all rules. The real world isn't that simple.

Here's the way I say it: if I expect derived classes, I should ask this question: who will create them? If the people who will create them will be outside your team, or if there are a huge number of derived classes, then and only then is it worth creating a protected interface and using private data. If I expect the derived classes to be created by my own team and to be reasonable in number, it's just not worth the trouble: use protected data. And hold your head up, don't be ashamed: it's the right thing to do!

I mostly agree with everything in that quote. The difference obviously being with protected interfaces, but even so, I never said they were never useful. Only that there are situations where they are inadequate.

The next question in the FAQ is also good. ROI is what it's about. Is making one member of method public going to make everything easier and move the project forward, or do you want to fiddle with the OO mechanism you were given to find a solution that 100% adheres to the textbook methodologies? Getting it done is often the right way to go when you can go back to fix it.

What I'm trying to say is don't interpret all of this as my using public everywhere. I don't. I use all three protection levels. I just tend to use protected more than others. And I don't frown on using a public method or two at times that solves polymorphism when protected polymorphism is impossible for example.