ACE_IPC_SAP的封装

对int_addr的封装是为了避免细节使用上的问题，那对ipc_sap的封装则是为了避免功能上的使用问题。 

一个sock可以充当3个角色：监听者、连接者和数据传递者。

你可能在一个需要监听者的地方传递了数据传递者，编译器不会给你任何提示，这是让我们无法容忍的，我们要创建一个规则阻止这样的行为，让他们是不同的类型就可以了，我们在这方面已经很有经验了。

由此我们对封装有了两点经验：1.当细节太多的时候使用函数，让编译器保证数据，2.当容易被错误使用的时候划分类型。

对于启动一个监听sock而言，我们要创建一个sock，设置addr，bing，listen，遗忘任何一个细节编译器也不会给于提示，这个时候最好的办法是聚合，也就是把他们放到一个函数里，允许程序员忘记事情，但是我这里只有一件事情，你忘记了不可能得到正确的结果，你也很容易知道错了，因为你什么都没做（只有一件事需要做，但是你忘了）。

封装的第3点思想是聚合化，这在单个C++类的设计中就被重视，为了避免函数过于庞大，我们划分函数功能，但是总不忘给使用者提供一个统一、唯一的接口。

其实对ipc_sap的封装讨论我只能想到这么多了，但是对于划分类型，这真是太难抉择了，他们本身就有很多公用的东西，划分开来有些东西要被写两遍，其实让他们继承于一个共有基类是非常自然的想法，也不用害怕，你的类型检查要求必须是某一个特定的子类，而基类是无法自动向子类转化的，一切依然是那么的美好，你也不必为类型划分付出多大代价。