COM是一个更好的C.pptVIP

抽象基类做为二进制接口 接口类的虚构函数不是虚函数 delete操作符无法递归的销毁派生对象 抽象基类做为二进制接口 方案1：将虚函数声明为纯虚函数，但纯虚函数在vbtl中的位置随编译器不同而不同 方案2：显式增加一个Delete方法，作为纯虚函数让派生类在方法实现中删除自身 抽象基类做为二进制接口 实现类的定义 抽象基类做为二进制接口 实现类的实现 抽象基类做为二进制接口 FastString类运行时内存结构 抽象基类做为二进制接口 在FastString DLL中，除了一个入口函数外，其他的入口函数均为纯虚函数 接口类虚函数通过vbtl中函数指针间接调用，不受“不同编译器之间符号改编方式不同”影响 唯一通过名字显示链接的CreateFastString采用extern “C”引出，避免符号改编方式的冲突 可以安全地在一个C++环境中开发，在另一个C++环境中访问调用 与编译器厂商无关的可重用组件模型 运行时动态性 动态加载DLL 运行时动态性 同一接口的不同实现间选择 对象扩展性 接口绝对不能改变，既是语义的规定，也是二进制结构的规定 接口加入新功能的方案1： 问题：破坏了接口的封装性；新接口遇到老对象会崩溃 对象扩展性 原则：接口公开后就不可改变 接口加入新功能的方案2： 一个接口继承自另一个相关的接口 实现类继承多个不相关的接口 COM是一个更好的C++ Written by Houlinlin C++的重用性 C++的一个主要目标是建立UDT（用户自定义类型） C++类库的出现 类库重用性的问题 问题1：NIH（not-invented-here） 问题2：封装后的逻辑强迫 问题3：库文档以源代码为参考起点 结论：C++对象模型不适合于可重用组件设计 软件分发与C++ FastString类，可以在O(1)时间内完成字串的搜索 软件分发与C++ FastString的实现 软件分发与C++ 多个应用同时运行 软件分发与C++ 操作系统中的多个应用程序间的重复代码 一旦链接无法替换FastString代码 FastString组件无模块化特征 动态链接与C++ 把FastString以动态链接库(DLL,Dynamic Link Library)的形式封装起来 动态链接与C++ FastString的所有方法加入DLL的引入表(export list) 链接器产生引入库(export library) 动态装载DLL到内存中 动态链接与C++ C++类向可重用的组件迈进的重要一步 可移植性和C++ C++的弱点：缺少二进制一级的标准 C++重载带来的问题：编译器可任意篡改入口点的名字 编译器厂商的专有特征：异常处理 结论：简单地从DLL中引出C++函数不足以建立“厂商独立的组件” 封装性和C++ 改造FastString，令其Length()函数的复杂度为O(1) 。 封装性和C++ 改写构造函数。 FastString::FastString(const char *psz) : m_cch(strlen(psz)), m_psz(new char[m_cch + 1]) { strcpy(m_psz, psz); } int FastString::Length(void) canst { return m_cch; II return cached length } 封装性和C++ C++支持语法上的封装性，却没有二进制层次上的封装性 C++编译器必须能够访问与对象内存布局有关的所有信息，这包括私有成员和公共成员的大小与顺序 封装性和C++ “简单地把C++类从DLL里引出来”并不能提供合理的二进制结构。 把接口从实现中分离出来 封装的概念以把“一个对象的外观（接口）与其实际工作方式（实现）分离”为基础 C++的问题在于没有在二进制层次上实现这种分离 解决方案：构造两个类，一个接口类，一个实现类。 把接口从实现中分离出来 接口类只描述希望客户知道的底层数据面貌 接口类不应包含任何用于对象实现的数据成员，应只包含操作方法的声明。 实现类将包含具体的数据成员与操作方法的具体实现。 把接口从实现中分离出来 接口类的二进制布局不会随着实现类数据成员的添加或删除而改变 FastString的声明不需要包含在头文件中 接口方法的机器码成为DLL的唯一引入点 把接口从实现中分离出来 接口类的实现方法只是把调用传给实现类 把接口从实现中分离出来 接口类的引入间接性地在客户和对象之间加入了一道二进制防火墙 它描述了客户与对象之间如何进行通信 简单的二进制协议，不依赖于C++实现类的任何细节 把接口从实现中分离出来 缺点： 方法调用需显式传给实现类 若类库方法过多，传递过程冗