23种设计模式含例题.docx

23种设计模式含例题.docx

《23种设计模式含例题.docx》由会员分享，可在线阅读，更多相关《23种设计模式含例题.docx（9页珍藏版）》请在冰豆网上搜索。

23种设计模式含例题

这里指出了关联的product！

所以说，一个Factory和一个Product是一一对应的关系。

创建型模式:

Factorymethod:

定义一个用于创建对象的接口，让子类决定实例化哪一个类。

FactoryMethod使一个类的实例化延迟到其子类

接口函数:

Creator:

:

FactoryMethod:

纯虚函数,由派生类实现,创建出对应的Product.

由相应的Factory派生类来生成Product的派生类,一个Factory和一个Product是一一对应的关系。

也就是说如果要新增一种Product那么也要对应的新增一个Factory。

每个factory负责自身产品创建的策略，保证各自的灵活性，符合单一职责原则。

Abstractfactory:

AbstractFactory模式是为创建一组（多类）相关或依赖的对象提供创建接口，而Factorymethod是为一类对象提供创建接口或延迟对象的创建到子类中实现。

AbstractFactory模式通常都是使用Factorymethod实现

每个具体工厂生产出不同的具体产品;根据不同产品的搭配各不相同。

Factory1生产A1、B1搭配出的产品，Factory2生产A2、B2搭配出的产品

Builder:

Builder模式是基于这样的一个情况:

一个对象可能有不同的组成部分,这几个部分的创建具有多样性,但是各个部分之间装配的方式是一致的.Director:

:

Construct函数中固定了各个组成部分的装配方式,而装配用到的具体组成部分由Builder的派生类实现.       多态的零件制造、一致的装配过程

完成各组件间的创建（多态的）

各零件组成了product

装配方式:

完成各组件间的关联、组装

接口:

Builder:

:

BuildPart（）…:

是对一个对象不同部分的构建函数接口,Builder的派生类来具体实现.

Director:

:

Construct（）通过调用上面的接口函数完成各个部分的装配

实现:

Builder模式基于以下几个面向对象的设计原则:

1）把变化的部分提取出来形成一个基类和对应的接口函数

2）采用聚合的方式聚合了会发生变化的基类,就是这里Director聚合了Builder类的指针.

适用于以下情况:

1）当创建复杂对象的算法应该独立于该对象的组成部分的装配方式时

2）当构造过程必须允许被构造的对象有不同的表示时

Prototype:

Prototype模式其实就是常说的"虚拟构造函数"，通过不同派生类的Clone（）完成"虚拟构造函数"的效果

“浅克隆”&“深克隆”

接口函数:

 Prototype:

:

Clone（）:

纯虚函数,根据不同的派生类来实例化创建对象.

Singleton:

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

Singleton模式其实是对全局静态变量的一个替代策略,在C++中是这样实现的:

1）提供一个类的静态成员变量,类的静态成员变量对于一个类的所有对象是惟一的

2）提供访问这个静态成员变量的静态成员函数,对类的所有对象而言也是惟一的.

结构性模式：

Adapter：

将一个类的接口转换成客户希望的另外一个接口。

Adapt模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

（;接口转换）

把完成同样的功能但是接口不能兼容的类，桥接在一起；这个模式使得复用旧的接口成为可能.

Target类和用户接口,通过Adapter桥接后,幕后变为Adaptee类实现

Bridge：

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

子类扁平化处理

A、类在两个维度上变化

B、Bridge是比多重继承更好的方案

扁平扩展….

Implementor:

:

OperationImpl（）:

定义了为实现Abstraction需要的基本操作,由派生类具体实现。

在Bridge模式中，系统被分为两个相对独立的部分，Abstraction是抽象部分，Implementor是实现部分，这两个部分可以互相独立地进行修改。

当需要从Abstraction派生一个子类时，不再通过继承方式实现，而是只需在Implementor中添加一个子类而已（;右边的这颗类树开始变得扁平….），Abstraction无需任何变化。

风格变得elegant！

尽量使用组合/聚合关系而不是继承关系:

"favorcompositionoverInheritance"

Bridge的实现方式和Builder十分相近,本质上是一样的,只是封装的内容不一样.共同点:

●抽象出来一个基类,这个基类里面定义了共性行为,形成接口函数

●聚合一个基类的指针,把这个指针的使用封装在一个函数中

Builder封装了不同的生成组成部分的方式,而Bridge封装了不同的实现方式.

Composite：

Composite使得用户对单个对象和组合对象的使用具有一致性。

（;图元的组合处理、文件和文件夹的复制）

component为基类,leaf为单个对象,composite为组合对象,内含一个component数据结构（比如:

array、tree）;

Composite模式是为解决组件之间的递归组合提供了很好的解决办法

接口函数:

Operatation（）:

共有的行为,由各个子类具体实现.

含有子组件的类：

Add（）,Remove（）,GetChild（）

应用情况：

●想要表示对象的整个或部分的层次结构

●需要客户端忽略复合对象和单个对象之间的差异

●结构可以具有任何级别的复杂性而且是动态的

Decorator：

动态地给一个对象添加一些额外的“装饰”。

Decorator模式比生成子类更为灵活，它不是通过继承实现的，而是通过组合。

通过继承的方式会带来系统的复杂性，因为继承的深度会变得很深。

 动态的添加装饰，提供了比继承更有弹性的替代方案

接口函数:

Operation（）:

Decorator类对component类的"装饰",是通过operation（）的多态调用实现的

Decorator的派生类装饰ConcreateComponent类的对象.实现要点是:

●Decorator和ConcreateComponent都继承自Component,;

●Decorator维护了一个指向Component的指针,从而可以实现对Operation（）的动态调用.

优点：

1、使得整个类树变得更扁平化;

2、“动态,透明”的方式来添加职责,使得父子类间的关系更简约化

应用情况：

●想要在单个对象中动态、透明的添加装饰，这样不会影响其他对象；

●想要在以后可能要修改的对象中添加职责

●无法通过静态子类化实现扩展时

Fa?

ade：

Facade外观模式为子系统中的各类（或结构与方法）提供一个简明一致的界面，隐藏子系统的复杂性，使子系统更加容易使用。

为子系统中的一组接口所提供的一个一致的界面（在日常开发中，早已大量应用）

Facade类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与Facade对象打交道，而不需要与子系统内部的很多对象打交道。

适用情况：

●为一个复杂子系统提供一个简单接口。

●提高子系统的独立性。

●在层次化结构中，可以使用Facade模式定义系统中每一层的入口。

FlyWeight：

Flyweight（享元模式）在大量使用可被共享的对象的时候经常使用。

当需要一个对象的时候,先去查询是否已经存在了,如果没有就生成，有的话就直接使用.   注意共性、个性的协调处理

FlyweightFactory是个对象构造工厂，拥有一个对象池（list实现）。

当Client需要一个对象时候就会向FlyweightFactory发出请求GetFlyweight（），GetFlyweight（）会遍历对象池中的对象，如果已经存在则直接返回,否则创建一个新的对象返回。

含有缓冲池，记录内容状态

外部对象，不可共享

内部对象，可共享

通过共享一个接口来避免使用多个具有相同信息的实例所带来的开销。

●避免大量相同对象造成的开销，通常是内存消耗

●各对象将共性进行共享，同时又保留自己的个性

Proxy：

为对象提供一种代理以控制对这个对象的访问。

至少在以下几种情况下可以用Proxy模式：

●RemoteProxy：

为网络上的对象创建一个局部的本地代理，比如要操作一个网络上的一个对象（网络性能不好的时候，问题尤其突出），我们将这个操纵的过程交给一个代理去完成；

●VirtualProxy：

创建开销大的对象时候，比如显示一幅大的图片，我们将这个创建的过程交给代理去完成；

●ProtectionProxy：

对对象进行控制访问的时候，比如论坛中不同权限的用户将获得不同层次的操作权限，我们将这个工作交给一个代理去完成

事后处理…..

事前处理：

权限、条件、拦截…..

在特定情景下，满足某种条件时，再调用RealSubject

Subject.Request（）:

定义了Proxy和RealSubject的公有接口,这样就可以在任何需要使用到RealSubject的地方都使用Proxy代理实现.

Proxy其实是基于这样一种时常使用到的技术-某个对象直到它真正被使用到的时候才被初始化,在没有使用到的时候就暂时用Proxy作一个占位符.这个模式实现的要点就是Proxy和RealSubject都继承自subject,确保了他们有共同的接口。

优点：

●远程代理可以隐藏对象位于不同的地址空间的事实

●虚拟代理可以执行优化操作，例如根据需要创建一个对象

注意：

Fa?

ade模式注重简化接口，Adapter模式注重转换接口，Bridge模式注重分离接口（抽象）与其实现，Decorator模式注重稳定接口的前提下为对象扩展功能。

行为性模式

ChainofResponsibility

ChainofResponsibility模式描述了这样一类问题：

将可能处理一个请求的对象联接成一个链，并将请求在这个链上传递，直到有对象处理该请求。

特别适用于：

链、节点的职责都具有动态性

接口：

Handler.HandleRequset（）处理请求，同时有一个指针successor,指向后继对象。

ConcreteHandler将自己的后继对象记录在自己的后继指针中，当一个请求到来时，ConcreteHandler会先检查看自己有没有匹配的处理程序，如果有就自己处理，否则传递给它的后继。