Protected or Private?

作为父类的设计者，你可能会踌躇到底应该使用protected还是private来描述你的成员。那么，让我们来看看下面几个Sample吧：

1、不相关的类访问protected成员

void B::yourfun(A &a)
{
    class ASpe:public A
    {
        friend class B;
    };
    static_cast<ASpe &>(a).ProtectFun();
}

尽管static_cast<ASpe &>的结果是undefined，但是因为这里的static_cast通常都是no-op，而且编译器一般都会对ASpe作空派生类优化，因此上面的代码在实际应用中几乎肯定可以成功。

对于一个恶意用户而言，他的目的已经达到了。

2、调用纯虚函数

class A {
protected:
    virtual void Fun() =0;
};

class B:public A
{
public:
    B() {Dummy();}

private:
    void Dummy() {Fun();}
};
class C:public B
{
public:
    virtual void Fun() {}
};

你觉得不可能调用传说中的纯虚函数？你想看看_purecall到底会作些什么？试试上面的代码吧。问题的根源在于父类将Fun声明成了protected。
当然你不应当在ctor里调用virtual函数，但是你在ctor调用Dummy的时候，并不一定会注意到Dummy内部会调用virtual函数，于是灾难发生了
如果你仅仅希望子类在virtual函数中提供某种行为，那么把这些函数声明成private吧

尽管上面的代码都不符合标准，但是至少说明，你的用户可以利用你提供的protected权限实现一些你并不希望赋予子类的功能。
如果你觉得连private都不放心（譬如邪恶的#define private public，当然它违反了标准17.4.3.1.1，因此结果是不可预期的），那么你最好使用PImpl来实现你的接口