How should I decide whether to build a “protected interface”?

Question

From: http://www.parashift.com/c++-faq-lite/basics-of-inheritance.html#faq-19.9

Three keys: ROI, ROI and ROI.

Every interface you build has a cost and a benefit. Every reusable component you build has a cost and a benefit. Every test case, every cleanly structured thing-a-ma-bob, every investment of any sort. You should never invest any time or any money in any thing if there is not a positive return on that investment. If it costs your company more than it saves, don't do it!

Not everyone agrees with me on this; they have a right to be wrong. For example, people who live sufficiently far from the real world act like every investment is good. After all, they reason, if you wait long enough, it might someday save somebody some time. Maybe. We hope.

That whole line of reasoning is unprofessional and irresponsible. You don't have infinite time, so invest it wisely. Sure, if you live in an ivory tower, you don't have to worry about those pesky things called "schedules" or "customers." But in the real world, you work within a schedule, and you must therefore invest your time only where you'll get good pay-back.

Back to the original question: when should you invest time in building a protected interface? Answer: when you get a good return on that investment. If it's going to cost you an hour, make sure it saves somebody more than an hour, and make sure the savings isn't "someday over the rainbow." If you can save an hour within the current project, it's a no-brainer: go for it. If it's going to save some other project an hour someday maybe we hope, then don't do it. And if it's in between, your answer will depend on exactly how your company trades off the future against the present.

The point is simple: do not do something that could damage your schedule. (Or if you do, make sure you never work with me; I'll have your head on a platter.) Investing is good if there's a pay-back for that investment. Don't be naive and childish; grow up and realize that some investments are bad because they, in balance, cost more than they return.

Well, I didn't understand how to correlate this to C++ protected interface.

Please give any real C++ examples to show what this FAQ is talking about.

Answer 1

First off, do not ever treat any programming reference as definitive. Ever. Everything is somebody's opinion, and in the end you should do what works best for you.

So, that said, what this text is basically trying to say is "don't use techniques that cost you more time than they save". One example of the "protected interface" they're describing is the following:

class C {
    public:
        int x;
};

Now, in Java, all the Java EE programming books will tell you to always implement that class like this:

class C {
    public:
        int getX() { return x; }
        void setX(int x) { this.x = x; }
    private:
        int x;
};

... that's an implementation of proper encapsulation (technical term: simplifying a little, it means minimizing sharing between discrete parts). The classes using your code are concerned that you have some way to get and set an integer, not that it's actually stored as an int inside the class. So if you use accessor methods, you're better able to change the underlying implementation later: maybe you want it to read that variable from the network?

However, that was a large amount of extra code (in terms of characters) and some extra complexity to implement that. Doing things properly actually has a cost! It's not a cost in terms of correctness of the code - directly - but you spent some number of minutes doing it "better" that you could have spent doing something else, and there is a nonzero amount of work involved in maintaining everything you write, no matter how trivial.

So, what is being said in this passage is in my mind good advice: always double-check that when you go to do something, you're going to get more out of it than what you put in. Sanity check that you are not following an ideal to the detriment of your actual effectiveness as a programmer or a human being.

That's advice that will serve you well in any programming language, and in any walk of life.

Answer 2

From your quote above, the guy sounds like a pedantic jerk :)

Looking at the previous entries in his FAQ, he's really saying the following:

1) A class has two distinct interfaces for two distinct sets of clients:

• It has a public interface that serves unrelated classes
• It has a protected interface that serves derived classes

2) Should you always go to the trouble of creating two different interfaces for each class?

3) Answer: "no, not necessarily"

• Sometimes it's worth the extra effort to create protected getter and setter methods, and make all data "private"

• Other times - he says - it's "good enough" to make the data itself "protected". Without doing all the extra work of writing a bunch of extra code, and incurring the consequent size and performance penalties.

  Sounds reasonable to me. Do what you need to do - but don't go overboard and do a bunch of unnecessary stuff in the name of "theory".

That's all he's saying - use good judgement, and don't go overboard.

You can't argue with that :)

PS:

FAQ's 19.5 through 19.9 in your link deal with "derived classes". None of this discussion is relevant outside of the question "how should I structure base classes for inheritance?" In other words, it's not a discussion about "classes" in general - only about "how should a super class best make things visible to it's subclasses?".