实际上功能完全一样，甚至比现在更节约内存（当m_bObject不用的时候，可以只是一个空指针）。而且此时class_a.h中不需要包含class_b.h。没有违反上面的原则2.

    但是不可否认，有时头文件中是必须使用头文件的，比如：

class MyClassA : public MyClassB 
{ 
}; 

     此时，#include “class_b.h”是有必要的。但是继承一般的来说，不是一个很好的主意。一般继承仅仅用于：基类是一个纯虚类的情况。现在多不主张多层次的复杂的继承关系。当然并不仅仅因为这样会带来多层次嵌套的#include头文件。后文再详细的讨论这些问题。

    另一个常见的必须使用头文件的情况是：我在类或者函数定义中用到了stl模块类。

void my_function(const string &str);

    此时在前面简单的声明：class string，往往是行不通的。必须#include <string>.但是，由于stl的头文件非常通用，几乎不会有人抱怨找不到这些头文件，所以在头文件中包含它们是一个可以接受的例外。
下面继续讨论头文件的问题。 


三. 头文件极简化

    头文件往往是代码质量的关键所在。因为我们往往是通过头文件，来提供给对方，可以使用的类或者函数。.c文件的部分可以重写，不影响其他的部分。而头文件则往往牵一发而动全身。所以头文件不可以不做小心谨慎的设计。随意的编写头文件是绝对错误的。

    头文件里包含其他头文件，还常常是因为用到特有的数据结构来返回结果导致的。下面举出另一个虚拟的例子：我打算编写一个模块，提供一个功能，让别人可以获得我本机上插的U盘的序列号。这是一个很明确的需求。我编写了usb_disk_id.c和usb_disk_id.h来提供这些功能。而使用这个模块的人，只要#include “usb_disk_id.h”然后调用我的函数就可以了。

   在开发的过程中，我借鉴了DDK中一个应用程序，名字叫做”usbview.exe”的代码。这个代码能显示每个USB盘的信息。所有的信息返回在一个链表中，每个节点定义如下：

typedef struct _STRING_DESCRIPTOR_NODE 
{ 
struct _STRING_DESCRIPTOR_NODE * Next; 
UCHAR DescriptorIndex; 
USHORT LanguageID; 
USB_STRING_DESCRIPTOR StringDescriptor[0]; 
} STRING_DESCRIPTOR_NODE, *PSTRING_DESCRIPTOR_NODE;