注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

HongMain 的博客

关注编程技术: Linux, Windows, C/C++

 
 
 

日志

 
 
 
 

聊聊封装、继承  

2011-08-06 11:39:47|  分类: 编程语言(主要是 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

      C++中封装的概念是把一个对象的外观接口同实际工作方式(实现)分离开来,但是C++的封装是不完全的,编译器必须知道一个对象的所有部分的声明,以便创建和管理它。我们可以想象一种只需声明一个对象的公共接口部分的编程语言,而将私有的实现部分隐藏起来。C + +在编译期间要尽可能多地做静态类型检查。这意味着尽早捕获错误,也意味着程序具有更高的效率。然而这对私有的实现部分来说带来两个影响:一是即使程序员不能轻易地访问实现部分,但他可以看到它;二是造成一些不必要的重复编译

            然而C++并没有将这个原则应用到二进制层次上,这是因为C++的类既是描述了一个接口同时也描述了实现的过程,示例如下:

 

聊聊封装、继承 - HongMain - HongMain 的博客class CMyString
聊聊封装、继承 - HongMain - HongMain 的博客
{
聊聊封装、继承 - HongMain - HongMain 的博客
private:
聊聊封装、继承 - HongMain - HongMain 的博客 
const int m_cch;
聊聊封装、继承 - HongMain - HongMain 的博客  
char *m_psz;
聊聊封装、继承 - HongMain - HongMain 的博客
public:
聊聊封装、继承 - HongMain - HongMain 的博客  CMyString(
const char *psz);
聊聊封装、继承 - HongMain - HongMain 的博客  
~CMyString();
聊聊封装、继承 - HongMain - HongMain 的博客  
int Length() const;
聊聊封装、继承 - HongMain - HongMain 的博客  
int Index(const char *psz) const;
聊聊封装、继承 - HongMain - HongMain 的博客}

聊聊封装、继承 - HongMain - HongMain 的博客

 

 

CMyStirng对外过多的暴露了内存布局实现的细节,这些信息过度的依赖于这些成员变量的大小和顺序,从而导致了客户过度依赖于可执行代码之间的二进制耦合关系,这样的接口不利于跨语言跨平台的软件开发和移植。

 

1.1.1      Handle-Body模式

 

       解决这个问题的技术有一种叫句柄类( handle classes。有关实现的任何东西都消失了,只剩一个单一的指针“m_pThis”。该指针指向一个结构,该结构的定义与其所有的成员函数的定义都出现在实现文件中。这样,只要接口部分不改变,头文件就不需变动。而实现部分可以按需要任意更动,完成后只要对实现文件进行重新编译,然后再连接到项目中。

       下面是这项技术的简单例子。头文件中只包含公共的接口和一个简单的没有完全指定的类指针。

 

聊聊封装、继承 - HongMain - HongMain 的博客class CMyStringHandle
聊聊封装、继承 - HongMain - HongMain 的博客
{
聊聊封装、继承 - HongMain - HongMain 的博客
private:
聊聊封装、继承 - HongMain - HongMain 的博客  
class CMyString;
聊聊封装、继承 - HongMain - HongMain 的博客  CMyString 
*m_pThis;
聊聊封装、继承 - HongMain - HongMain 的博客
public:
聊聊封装、继承 - HongMain - HongMain 的博客  CMyStringHandle (
const char *psz);
聊聊封装、继承 - HongMain - HongMain 的博客  
~ CMyStringHandle ();
聊聊封装、继承 - HongMain - HongMain 的博客  
int Length() const;
聊聊封装、继承 - HongMain - HongMain 的博客  
int Index(const char *psz) const;
聊聊封装、继承 - HongMain - HongMain 的博客}

聊聊封装、继承 - HongMain - HongMain 的博客
聊聊封装、继承 - HongMain - HongMain 的博客CMyStringHandle:: CMyStringHandle(
const char *psz)
聊聊封装、继承 - HongMain - HongMain 的博客:m_pThis(
new CMyString(psz));
聊聊封装、继承 - HongMain - HongMain 的博客
{
聊聊封装、继承 - HongMain - HongMain 的博客}

聊聊封装、继承 - HongMain - HongMain 的博客
聊聊封装、继承 - HongMain - HongMain 的博客CMyStringHandle::
~ CMyStringHandle()
聊聊封装、继承 - HongMain - HongMain 的博客
{
聊聊封装、继承 - HongMain - HongMain 的博客   delete m_pThis;
聊聊封装、继承 - HongMain - HongMain 的博客}

聊聊封装、继承 - HongMain - HongMain 的博客
聊聊封装、继承 - HongMain - HongMain 的博客
int CMyStringHandle::Length()
聊聊封装、继承 - HongMain - HongMain 的博客
{
聊聊封装、继承 - HongMain - HongMain 的博客  
return m_pThis->Length();
聊聊封装、继承 - HongMain - HongMain 的博客}

聊聊封装、继承 - HongMain - HongMain 的博客
聊聊封装、继承 - HongMain - HongMain 的博客
int CMyStringHandle::Index(const char *psz)
聊聊封装、继承 - HongMain - HongMain 的博客
{
聊聊封装、继承 - HongMain - HongMain 的博客 
return m_pThis->Index(psz);
聊聊封装、继承 - HongMain - HongMain 的博客}

聊聊封装、继承 - HongMain - HongMain 的博客

 

    这是所有客户程序员都能看到的。
            class CMyString

是一个没有完全指定的类型说明或类声明(一个类的定义包含类的主体)。它告诉编译器,CMyString是一个结构的名字,但没有提供有关该结构的任何东西。这对产生一个指向结构的指针来说已经足够了。但我们在提供一个结构的主体部分之前不能创建一个对象。在这种技术里,包含具体实现的结构主体被隐藏在实现文件中。

 

            在设计模式中,这就叫做Handle-Body 模式,Handle-Body只含有一个实体指针,服务的数据成员永远被封闭在服务系统中。

Handle-Body的布局结构永远不会随着实现类数据成员的加入或者删除或者修改而导致Handle-Body的修改,即Handle-Body协议不依赖于C++实现类的任何细节。这就有效的对用户的编译器隐藏了这些细节,用户在使用对这项技术时候,Handle-Body 接口成了它唯一的入口。

 

然而Handle-Body模式也有自己的弱点:

1、接口类必须把每一个方法调用显示的传递给实现类,这在一个只有一个构造和一个析构的类来说显然不构成负担,但是如果一个庞大的类库,它有上百上千个方法时候,光是编写这些方法传递就有可能非常冗长,这也增加了出错的可能性。

2、对于关注于性能的应用每一个方法都得有两层的函数调用,嵌套的开销也不理想

3、由于句柄的存在,依然存在编译连接器兼容性问题。

 

1.1.2        抽象接口

            使用了“接口与实现的分离”技术的 Handle-Body 解决了编译器/链接器的大部分问题,而C++面向对象编程中的抽象接口同样是运用了“接口与实现分离”的思想,而采用抽象接口对于解决这类问题是一个极其完美的解决方案。

1、抽象接口的语言描述:

            class IMyString

            {

              virtual int Length() const = 0; //这表示是一个纯虚函数,具有纯虚函数的接口

              virtual int Index(const char *psz) const = 0;

            }

 

2、抽象接口的内存结构:

        抽象接口采用虚函数表来调用成员方法。 

3、   抽象接口的实现代码:

              接口:

            class IMyString

            {

              virtual int Length() const = 0; //这表示是一个纯虚函数,具有纯虚函数的接口

              virtual int Index(const char *psz) const = 0;

            }

             实现:

            class CMyStringpublic IMyString

            {

            private:

             const int m_cch;

              char *m_psz;

            public:

              CMyString(const char *psz);

              virtual ~CMyString();

              int Length() const;

              int Index(const char *psz) const;

            }

            从上面采用抽象接口的实例来看,抽象接口解决了Handle-Body所遗留下来的全部缺陷。

抽象接口的一个典型应用:

            抽象工厂(AbstractFactroy

 

1.2       多继承与菱形缺陷、this跳转等

多重继承是C++语言独有的继承方式,其它几乎所有语言都秉承了单一继承的思想。这是因为多重继承致命的缺陷导致的:

1.2.1        菱形缺陷

当继承基类时,在派生类中就获得了基类所有的数据成员副本。假如类B A1A2两个类多重继承而来,这样B类就包含A1A2类的数据成员副本。

考虑如果A1A2都从某基类派生,该基类称为Base,现在继承关系将出现菱形继承关系。

聊聊封装、继承 - HongMain - HongMain 的博客

我们C++语言来描述这种继承关系:

 

class Base{ }

class A1 :public Base { }

class A2 :public Base { }

class B :public A1,public A2 { }

 

那么A1A2都具有Base的副本。这样B就包含了Base的两个副本,副本发生了重叠,不但增加了存储空间,同时也引入了二义性。这就是菱形缺陷,菱形缺陷的两个缺陷:

1、子对象重叠

2、向上映射的二义性。

菱形缺陷的其中一种解决办法是使用虚拟继承。

 

C++世界里最广泛的使用虚拟继承解决菱形缺陷的应用便是标准C++的输入/输出iostream

聊聊封装、继承 - HongMain - HongMain 的博客

 

 

 

1.2.2        多重接口与方法名冲突问题(Siamese twins

       对继承而来的虚函数改写很容易,但是如果是在改写一个“在两个基类都有相同原型”的虚函数情况就不那么容易了。

       提出问题:

       假设汽车最大速度的接口为ICar,潜艇最大速度的接口为 IBoat,有一个两栖类的交通工具它可以奔跑在马路上,也可以航行在大海中,那么它就同时拥有ICarIBoat两种交通工具的最大速度特性,我们定义它的接口为ICarBoat

       class ICar

       {

             virtual int GetMaxSpeed()= 0

       }

       class IBoat

       {

      virtual int GetMaxSpeed()= 0

       }

   我们先对ICarBoat的接口做一个尝试:

       class CCarBoat

       {

              virtual int GetMaxSpeed();//既完成ICarGetMaxSpeed()接口方法又                                     //完成IBoat的接口方法?显然不能够

       };

解决问题:

       显然上面这个尝试根本就无法成功,只用一个实现方法,怎么能够求出这个ICarBoat交通工具奔跑在马路上的最高时速,同时也能够求出航行在大海上的最大航行速度呢。

       上面这一问题矛盾就在一一个方法,却需要两个答案。看来ICarBoat要返回两个答案就必须有两个方法了,我们假设一个方法是求在陆地上奔跑的速度,名称为GetCarMaxSpeed();另一个方法是求在大海上航行的最大速度,名称为GetBoatMaxSpeed();那这两个方法又怎么和GetMaxSpeed()接口方法联系起来呢;

 

       幸运的是,我们找到了解决办法,而且解决办法有很多种,下面介绍一下继承法。

       class IXCar :public ICar

       {

             virtual int GetMaxSpeed()

              {

                     GetCarMaxSpeed();

              }

              virtual int GetCarMaxSpeed() = 0;

       }

       class IXBoat:public IBoat

       {

              virtual int GetMaxSpeed()

              {

                     GetBoatMaxSpeed();

              }

              virtual int GetBoatMaxSpeed() = 0;

       }

       classCCarBoat: public IXCar , public IXBoat

       {

              virtual int GetCarMaxSpeed()

              {

                     … …

              }

              virtual int GetBoatMaxSpeed()

              {

                     … …

              }

       };

      

聊聊封装、继承 - HongMain - HongMain 的博客

 

           

1.2.3        this跳转

this跳转是指的“对象同一性”问题。

      在单一继承的世界内,无论继承关系怎么复杂,针对于同一对象,无论它的子类或者父类的this指针永远相等。即如果 BA继承,那么 对于一个已经实例化B类的对象 bObject,永远有(B*&bObject ==(A*)&bObject 成立。

      但是在多继承的世界内,上面的等式就不能恒成立,对象的同一性受到了挑战。

      特别的是,在多继承世界内如果菱形关系存在情况下,如果对于已经实例化B类的对象bObject; Base*)(A1*&bObject != Base*)(A2*&bObject 成立,当这种事情发生的时候我们就只能特殊处理了。这种情况在COM应用中处处都会发生。

 

1.3       C++多态的两种多态形式和区别

     C++有两种多态多态形式:

1、编译时刻多态,编译时刻多态依靠函数重载或者模板实现

2、运行时刻多态。运行时刻多态依靠需函数虚接口实现

  评论这张
 
阅读(10)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017