重读《设计模式》之学习笔记(二)--再论接口与实现的分离

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/starlee/article/details/644525

    在我的那篇《C++中接口与实现分离的技术》我用具体的代码说明了C++中接口与实现分离的技术,并指出这样的三点好处:1、只暴露了类的接口而隐藏了实现细节;2、在类的实现有变动的时候,用户不需要更新头文件,不用重新编译;3、在分析阶段设计接口,在编码阶段来实现功能,可以更好的维护和升级。
    本书作者在2.6.3提到了Window和WindowImp,指出WindowImp类层次用来隐藏不同窗口系统的实现的。下面是书中的类图:

    书中的这种方法给了我们一个更好的使用接口与实现分离技术的理由:可以封装类的不同实现。比如我们要设计一个字符串类ClxString,要求有一个设备无关的输出函数lxOut()。也就是说,用户在使用我们的输出函数lxOutput()的时候是不管字符串是输出到显示器还是打印机或者其他一些输出设备的。于是,我们可以设计出跟书中相似的类结构:

    这样输出到显示器还是打印机对类ClxString的用户来说就是透明的了,实现细节被隐藏起来。在这种情况下,我们可以用类ClxStringImp来配置类ClxString,使数据输出到不同的输出设备。为了实现输出设备的可配置,我们可以增添一个工厂,里面用不同的工厂方法来得到不同的输出设备:

class COutputFactory
{
public:
    ClxOutputSet
* CreateDisplay() const
    { 
return new ClxDisplay; };

    ClxOutputSet
* CreatePrint() const
    { 
return new ClxPrint; };
};

    新的类图如下:

    类ClxStringImp的构造函数是下面的形式:

ClxStringImp::ClxStringImp
{
    m_pOutputFactory 
= new COutputFactory;
    m_pOutputSet 
= COutputFactory->CreateDisplay();
}

   我们就可以利用C++的多态性,在lxOutput()函数里调用m_pOutputSet的lxOut()来实现字符串输出到不同的输出设备。如果我们又增添了直接输出到文件的方法,我们只要从类ClxOutputSet继承一个新的输出类ClxFile并对类COutputFactory和类ClxStringImp进行很小的修改就行了。如果想做到对类的修改最小,可以把类CoutputFactory设计成如下的样子:

class COutputFactory
{
public:
    ClxOutputSet
* CreateOutputSet() const
    {
        #ifdef _LXDISPLAY
            
return new ClxDisplay;
        
#endif

        #ifdef _LXPRINT
            
return new ClxPrint;
        
#endif
    };
};

    那我们就可以得到如下的类ClxStringImp的构造函数:

ClxStringImp::ClxStringImp
{
    m_pOutputFactory 
= new COutputFactory;
    m_pOutputSet 
= COutputFactory->CreateOutputSet();
}

    如果采用这种方法的话,我们又把类ClxStringImp与类ClxOutputSet的实现进行了分离。无论我们对字符串的输出方法做了什么修改,或者是增添、减少输出设备,类ClxStringImp都不会被影响。那样我们就可以进行如下的分工:系统分析员负责定义类ClxString的各个接口,类ClxStringImp的开发人员只负责字符串的各种功能的实现,而不同的输出则由对输出设备比较了解的开发人员来实现。这样不仅可以使代码的可维护性提高,也使人力资源的分配达到了最优。
    而通过上面的方法,我们封装了类ClxString的不同实现。对用户来说,在输出字符串时他使用的只是类ClxString的接口lxOutput(),而具体的实现细节他是完全不知道的--他只知道字符串被输出,而不知道输出到什么地方。我们可以用《C++中接口与实现分离的技术》的方法来组织文件的依赖关系。那样,无论我们对类ClxStringImp的实现做了什么修改,用户都不用修改自己的代码,也不用重新编译自己的程序。

再论接口与抽象类

10-16

[size=10px][b]详解接口和抽象类rn相似性:rn1:两者都可以看作是抽象类,因此不能被直接实例化,可以声明接口或抽象类变量。rn解释:不能直接用new关键字生成接口或者抽象类的实例,实例化在子类中实现。rn2:两者都可以看作是需要被继承(实现)的,实例化发生在子类对象实例的生成。rn解释:接口和抽象类都是别人的嫁衣,定义了相应的规范,是一种行为约束。rn3:两者的非私有成员变量都可以在子类中被引用。rn解释:实现接口或继承抽象类都可以获得接口或抽象类的成员变量,也就是属性。rn4:两者的抽象成员方法都是只有方法定义体而不能有方法实现。rn解释:语言本身的原则,不需要太多的为什么,正是需要被实现或者继承的原因所在。rn5:两者的所有抽象成员方法必须在实现或者继承它们的子类中全部实现。rn解释:语言本身的原则,若非如此,这些方法岂不是没有用武之地,删除得了。rn6:两者的所有抽象成员方法在实现或者继承它们的子类中实现时,要具有相同的方法名、返回值类型、参数个数、参数类型和参数顺序。rn解释:这才体现了作为实现或者继承方的诚意,要遵循抽象出来的规范。rn不同点:rn1:接口是用来实现的;抽象类是用来继承的。rn解释:表达上更贴切实质一些,对两者进行一下区分,也可以理解为不尽相同的继承。rn2:接口实现关键字implements;抽象类的继承关键字extends。rn解释:这个还需要解释吗?这个语言本身定义的规范,服从----有时候是一种聪明的选择。rn3:一个类可以实现多个接口,一个类最多可以继承一个抽象类。rn解释:完全面向对象语言本身就不支持多重继承,接口是一个很好的解决方案。rn4:接口的所有成员方法都必须是抽象方法;抽象类的成员方法可以有抽象方法。rn解释:没什么好说的,接口内的方法必须都是抽象方法,抽象类可能有抽象方法。rn5:接口中所有成员不能被定义成private;抽象类中抽象方法不能被定义成private。rn解释:不同点4可以解释为什么会是这样。rnrnrnrn以上是个人联系理论并加以测试实践总结的,疏漏之处在所难免,将不断完善,也请各路高手不吝赐教,提出宝贵意见。rn[/b][/size]

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试

关闭