设计模式C++.docx

上传人:b****3 文档编号:2983688 上传时间:2022-11-16 格式:DOCX 页数:24 大小:270.08KB
下载 相关 举报
设计模式C++.docx_第1页
第1页 / 共24页
设计模式C++.docx_第2页
第2页 / 共24页
设计模式C++.docx_第3页
第3页 / 共24页
设计模式C++.docx_第4页
第4页 / 共24页
设计模式C++.docx_第5页
第5页 / 共24页
点击查看更多>>
下载资源
资源描述

设计模式C++.docx

《设计模式C++.docx》由会员分享,可在线阅读,更多相关《设计模式C++.docx(24页珍藏版)》请在冰豆网上搜索。

设计模式C++.docx

设计模式C++

1创建型模式

1.1Factory模式

􀂄问题

在面向对象系统设计中经常可以遇到以下的两类问题:

1)为了提高内聚(Cohesion)和松耦合(Coupling),我们经常会抽象出一些类的公共接口以形成抽象基类或者接口。

这样我们可以通过声明一个指向基类的指针来指向实际的子类实现,达到了多态的目的。

这里很容易出现的一个问题n多的子类继承自抽象基类,我们不得不在每次要用到子类的地方就编写诸如new×××;的代码。

这里带来两个问题1)客户程序员必须知道实际子类的名称(当系统复杂后,命名将是一个很不好处理的问题,为了处理可能的名字冲突,有的命名可能并不是具有很好的可读性和可记忆性,就姑且不论不同程序员奇百怪的个人偏好了。

),2)程序的扩展性和维护变得越来越困难。

2)还有一种情况就是在父类中并不知道具体要实例化哪一个具体的子类。

这里的意思为:

假设我们在类A中要使用到类B,B是一个抽象父类,在A中并不知道具体要实例化那一个B的子类,但是在类A的子类D中是可以知道的。

在A中我们没有办法直接使用类似于new×××的语句,因为根本就不知道×××是什么。

以上两个问题也就引出了Factory模式的两个最重要的功能:

1)定义创建对象的接口,封装了对象的创建;

2)使得具体化类的工作延迟到了子类中。

􀂄模式选择

我们通常使用Factory模式来解决上面给出的两个问题。

在第一个问题中,我们经常就是声明一个创建对象的接口,并封装了对象的创建过程。

Factory这里类似于一个真正意义上的工厂(生产对象)。

在第二个问题中,我们需要提供一个对象创建对象的接口,并在子类中提供其具体实现(因为只有在子类中可以决定到底实例化哪一个类)。

第一中情况的Factory的结构示意图为:

图1

图1:

Factory模式结构示意图1

图1所以的Factory模式经常在系统开发中用到,但是这并不是Factory模式的最大威力所在(因为这可以通过其他方式解决这个问题)。

Factory模式不单是提供了创建对象的接口,其最重要的是延迟了子类的实例化(第二个问题),以下是这种情况的一个Factory的结构示意图:

图2:

Factory模式结构示意图1

图2中关键中Factory模式的应用并不是只是为了封装对象的创建,而是要把对象的创建放到子类中实现:

Factory中只是提供了对象创建的接口,其实现将放在Factory的子类ConcreteFactory中进行。

这是图2和图1的区别所在。

􀂄实现

􀂋完整代码示例(code)

Factory模式的实现比较简单,这里为了方便初学者的学习和参考,将给出完整的实现代码(所有代码采用C++实现,并在VC6.0下测试运行)。

代码片断1:

Product.h

//Product.h

#ifndef_PRODUCT_H_

#define_PRODUCT_H_

classProduct

{

public:

virtual~Product()=0;

protected:

Product();

private:

};

classConcreteProduct:

publicProduct

{

public:

~ConcreteProduct();

ConcreteProduct();

protected:

private:

};

代码片断2:

Product.cpp

//Product.cpp

#include"Product.h"

#include

usingnamespacestd;

Product:

:

Product()

{

}

Product:

:

~Product()

{

}

ConcreteProduct:

:

ConcreteProduct()

{

cout<<"ConcreteProduct...."<

}

ConcreteProduct:

:

~ConcreteProduct()

{

}

代码片断3:

Factory.h

//Factory.h

#ifndef_FACTORY_H_

#define_FACTORY_H_

classProduct;

classFactory

{

public:

virtual~Factory()=0;

virtualProduct*CreateProduct()=0;

protected:

Factory();

private:

};

classConcreteFactory:

publicFactory

{

public:

~ConcreteFactory();

ConcreteFactory();

Product*CreateProduct();

protected:

private:

};

#endif//~_FACTORY_H_

代码片断4//Factory.cpp

#include"Factory.h"

#include"Product.h"

#include

usingnamespacestd;

Factory:

:

Factory()

{

}

Factory:

:

~Factory()

{

}

ConcreteFactory:

:

ConcreteFactory()

{

cout<<"ConcreteFactory....."<

}

ConcreteFactory:

:

~ConcreteFactory()

{

}

Product*ConcreteFactory:

:

CreateProduct()

{

returnnewConcreteProduct();

}

代码片断5:

main.cpp

//main.cpp

#include"Factory.h"

#include"Product.h"

#include

usingnamespacestd;

intmain(intargc,char*argv[])

{

Factory*fac=newConcreteFactory();

Product*p=fac->CreateProduct();

return0;

}

􀂋代码说明

示例代码中给出的是Factory模式解决父类中并不知道具体要实例化哪一个具体的子类的问题,至于为创建对象提供接口问题,可以由Factory中附加相应的创建操作例如Create***Product()即可。

具体请参加讨论内容。

􀂄讨论

Factory模式在实际开发中应用非常广泛,面向对象的系统经常面临着对象创建问题:

要创建的类实在是太多了。

而Factory提供的创建对象的接口封装(第一个功能),以及其将类的实例化推迟到子类(第二个功能)都部分地解决了实际问题。

一个简单的例子就是笔者开开发VisualCMCS系统的语义分析过程中,由于要为文法中的每个非终结符构造一个类处理,因此这个过程中对象的创建非常多,采用Factory模式后系统可读性性和维护都变得elegant许多。

Factory模式也带来至少以下两个问题:

1)如果为每一个具体的ConcreteProduct类的实例化提供一个函数体,那么我们可能不得不在系统中添加了一个方法来处理这个新建的ConcreteProduct,这样Factory的接口永远就不肯能封闭(Close)。

当然我们可以通过创建一个Factory的子类来通过多态实现这一点,但是这也是以新建一个类作为代价的。

2)在实现中我们可以通过参数化工厂方法,即给FactoryMethod()传递一个参数用以

决定是创建具体哪一个具体的Product(实际上笔者在VisualCMCS中也正是这样做的)。

当然也可以通过模板化避免1)中的子类创建子类,其方法就是将具体Product类作为模板参数,实现起来也很简单。

可以看出,Factory模式对于对象的创建给予开发人员提供了很好的实现策略,但是Factory模式仅仅局限于一类类(就是说Product是一类,有一个共同的基类),如果我们要为不同类的类提供一个对象创建的接口,那就要用AbstractFactory了。

2.2Adapter模式

􀂄问题

Adapter模式解决的问题在生活中经常会遇到:

比如我们有一个Team为外界提供S类服务,但是我们Team里面没有能够完成此项人物的member,然后我们得知有A可以完成这项服务(他把这项人物重新取了个名字叫S’,并且他不对外公布他的具体实现)。

为了保证我们对外的服务类别的一致性(提供S服务),我们有以下两种方式解决这个问题:

1)把B君直接招安到我们Team为我们工作,提供S服务的时候让B君去办就是了;

2)B君可能在别的地方有工作,并且不准备接受我们的招安,于是我们Team可以想这样一种方式解决问题:

我们安排C君去完成这项任务,并做好工作(Money:

))让A君工作的时候可以向B君请教,因此C君就是一个复合体(提供S服务,但是是B君的继承弟子)。

实际上在软件系统设计和开发中,这种问题也会经常遇到:

我们为了完成某项工作购买了一个第三方的库来加快开发。

这就带来了一个问题:

我们在应用程序中已经设计好了接口,与这个第三方提供的接口不一致,为了使得这些接口不兼容的类(不能在一起工作)可以在一起工作了,Adapter模式提供了将一个类(第三方库)的接口转化为客户(购买使用者)希望的接口。

在上面生活中问题的解决方式也就正好对应了Adapter模式的两种类别:

类模式和对象模式。

􀂄模式选择

Adapter模式典型的结构图为:

图2-1:

AdapterPattern(类模式)结构图

图2-2:

AdapterPattern(对象模式)结构图

在Adapter模式的结构图中可以看到,类模式的Adapter采用继承的方式复用Adaptee的接口,而在对象模式的Adapter中我们则采用组合的方式实现Adaptee的复用。

有关这些具体的实现和分析将在代码说明和讨论中给出。

􀂄实现

􀂋完整代码示例(code)

Adapter模式的实很简单,这里为了方便初学者的学习和参考,将给出完整的实现代码(所有代码采用C++实现,并在VC6.0下测试运行)。

类模式的Adapter实现:

代码片断1:

Adapter.h

//Adapter.h

#ifndef_ADAPTER_H_

#define_ADAPTER_H_

classTarget

{

public:

Target();

virtual~Target();

virtualvoidRequest();

protected:

private:

};

classAdaptee

{

public:

Adaptee();

~Adaptee();

voidSpecificRequest();

protected:

private:

};

classAdapter:

publicTarget,privateAdaptee

{

public:

Adapter();

~Adapter();

voidRequest();

protected:

private:

};

#endif//~_ADAPTER_H_

代码片断2:

Adapter.cpp

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 医学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1