前言

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

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

正文

先来看一段例子:

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

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

 1 // A.h 2 #include "B.h" 3 class A { 4 private: 5     B b; 6 }; 7  8 // B.h 9 #include "A.h"10 class B {11 private:12     A a;13 };

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

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

解决方案?

// A.hclass B;class A {public:    A();    ~A();private:    B *pB;};// A.cpp#include "B.h"A::A(): pB(new B()){}A::~A(){    delete pB;}// B.hclass 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.hclass 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的缺陷也是显而易见的.

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