前言

你是否总因头文件包含冲突而苦恼?
你是否因头文件包含错乱而苦恼?
你是否因封装暴露了数据而苦恼?
你是否因经常改动实现而导致重新编译而苦恼?

在这里, 这些问题都不是问题, 跟随作者, 揭秘pimpl.

正文

先来看一段例子:

有A, B 2个类, 分别由A.h, A.cpp, B.h, B.cpp文件实现.

同时, A类中包含了B类成员, B类中包含了A类成员.

 // A.h
 #include "B.h"
 class A {
 private:
     B b;
 };

 // B.h
 #include "A.h"
 class B {
 private:
     A a;
 };

你是否一眼就看出了问题!

是的, 头文件互相包含了, 那怎么解决此问题?

解决方案?

// A.h
class B;

class A {
public:
    A();
    ~A();
private:
    B *pB;
};

// A.cpp
#include "B.h"
A::A(): pB(new B())
{
}
A::~A()
{
    delete pB;
}

// B.h
class A;

class B {
public:
    B();
    ~B();
private:
    A *pA;
};

// B.cpp
#include "A.h"
B::B(): pA(new A())
{
}
B::~B()
{
    delete pA;
}

我们在头文件中互相前置声明, 这种行为是"不要钱"的, 大伙可以尽情的用.

随后在源文件中, 互相包含头文件, 在各自的构造函数中new 出对象, 析构函数中 delete 对象.

仅此而已?

接下来才是pimpl的重度解说.

假设我们的A需要实现成员函数 AmemberFunc.

这个成员函数过程复杂, 可能需要分割成多个小函数.

因此就有了一下清单:

func1();

func2();

...

funcN();

过程中还需要一系列成员变量.

因此就有了一下清单:

type1 var1, var2 ... varN;

type2 var1, var2 ... varN;

...

typeN var1, var2 ... varN;

注意, 你需要的仅仅是使用A的AmemberFunc接口.

其他的任何东西在你眼里都是累赘, 他们并不能让你更清楚实现, 反而扰乱你的思绪.

当你使用一个只有一个接口的对象时, 查看其头文件, 发现一堆的成员清单,

如果你胆子比较大, 或许会去源文件查看清单中的东西到底都在干什么.

这个时候的你已经走向歧途了.

当然, 也可能源文件已经被编译成了库文件, 你的壮志雄心不得已施展.

再次注意, 你需要的仅仅是这个接口, 至于接口的实现... 除非你的目的是把这个接口一探究竟, 否则纯属浪费时间.

废话说了不少, 看看解决方案.

// A.h
class A {
public:
    A();
    ~A();
    type memberFunc();
private:
    class impl;
    impl *pimpl;
};

// A.cpp
#include "B.h"
class A::impl {
    type memberFunc()
    {
        ...
    }
private:
    func1();
    func2();
    ...
    funcN();

    type1 var1, var2 ... varN;
    type2 var1, var2 ... varN;
    ...
    typeN var1, var2 ... varN;
};

A::A(): pimpl(new impl())
{

}

A::~A()
{
    delete pimpl;
}
type A::memberFunc()
{
    return pimpl->memberFunc();
}

A的内部声明了一个impl类型.

该类实例负责实现A的所有功能.

A只需调用impl相应的函数.

此方法隐藏了所有不需要暴露的细节.

并且避免了头文件的依赖. (因为实现在源文件中, 你可以在里面包含任意头文件不必考虑冲突问题.)

增强了可读性, 用户不会被"细节"扰乱思绪.

尾声

pimpl的功能远不止这些, 你可以在pimpl中抛出异常, 在外层类中捕获异常, 从而让异常完全透明.

还有更多功能, 等着你去发现..

当然, pimpl的缺陷也是显而易见的.

那就是不能内联! 不过谁会在意呢.