常见的10种设计模式.docx

常见的10种设计模式.docx

《常见的10种设计模式.docx》由会员分享，可在线阅读，更多相关《常见的10种设计模式.docx（12页珍藏版）》请在冰点文库上搜索。

常见的10种设计模式

设计模式

1简单工厂模式

简单工厂模式属于类的创建型模式,又叫做静态工厂方法模式。

通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

工厂（Creator）角色

简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。

工厂类可以被外界直接调用，创建所需的产品对象。

抽象（Product）角色

简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。

具体产品（ConcreteProduct）角色简单工厂模式所创建的具体实例对象

优缺点

在这个模式中，工厂类是整个模式的关键所在。

它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。

用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。

有利于整个软件体系结构的优化。

简单工厂模式的缺点也正体现在其工厂类上，由于工厂类集中了所有实例的创建逻辑，所以“高内聚”方面做的并不好。

另外，当系统中的具体产品类不断增多时，可能会出现要求工厂类也要做相应的修改，扩展性并不很好。

2工厂方法模式

工厂方法模式同样属于类的创建型模式又被称为多态工厂模式。

工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。

核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。

抽象工厂（Creator）角色：

工厂方法模式的核心，任何工厂类都必须实现这个接口。

具体工厂（ConcreteCreator）角色:

抽象工厂的一个实现，负责实例化产品对象。

抽象（Product）角色:

工厂方法模式所创建的所有对象的父类，它负责描述所有

实例所共有的公共接口。

具体产品（ConcreteProduct）角色:

工厂方法模式所创建的具体实例对象工厂方法模式与工厂模式的比较:

工厂方法模式与简单工厂模式在结构上的不同不是很明显。

工厂方法类的核心是一个抽象工厂类，而简单工厂模式把核心放在一个具体类上。

工厂方法模式之所以有一个别名叫多态性工厂模式是因为具体工厂类都有共同的接口，或者有共同的抽象父类。

当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，很好的符合了“开放－封闭”原则。

而简单工厂模式在添加新产品对象后不得不修改工厂方法，扩展性不好。

工厂方法模式退化后可以演变成简单工厂模式

3抽象工厂模式

抽象工厂模式是所有形态的工厂模式中最为抽象和最其一般性的。

抽象工厂

模式可以向客户端提供一个接口，使得客户端在不必指定产品的具体类型的情况下，能够创建多个产品族的产品对象。

抽象工厂（Creator）角色

抽象工厂模式的核心，包含对多个产品结构的声明，任何工厂类都必须实现这个接口。

具体工厂（ConcreteCreator）角色

具体工厂类是抽象工厂的一个实现，负责实例化某个产品族中的产品对象。

抽象（Product）角色

抽象模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。

具体产品（ConcreteProduct）角色

抽象模式所创建的具体实例对象

总结：

抽象工厂中方法对应产品结构，具体工厂对应产品族。

4单例模式

单例模式是一种对象创建型模式，使用单例模式，可以保证为一个类只生成

唯一的实例对象。

也就是说，在整个程序空间中，该类只存在一个实例对象。

其实，GoF对单例模式的定义是：

保证一个类、只有一个实例存在，同时提供能对该实例加以访问的全局访问方法。

为什么要使用单例模式呢？

在应用系统开发中，我们常常有以下需求：

-在多个线程之间，比如servlet环境，共享同一个资源或者操作同一个对象

-在整个程序空间使用全局变量，共享资源

-大规模系统中，为了性能的考虑，需要节省对象的创建时间等等。

因为Singleton模式可以保证为一个类只生成唯一的实例对象，所以这些情况，

Singleton模式就派上用场了。

单例模式实现

1.饿汉式。

2.懒汉式。

3.双重检查。

5.代理模式

Proxy模式又叫做代理模式，是构造型的设计模式之一，它可以为其他对象提供一种代理（Proxy）以控制对这个对象的访问。

所谓代理，是指具有与代理元（被代理的对象）具有相同的接口的类，客户端必须通过代理与被代理的目标类交互，而代理一般在交互的过程中（交互前后），进行某些特别的处理。

代理模式的结构

代理模式的角色和职责

subject（抽象主题角色）：

真实主题与代理主题的共同接口。

RealSubject（真实主题角色）：

定义了代理角色所代表的真实对象。

Proxy（代理主题角色）：

含有对真实主题角色的引用，代理角色通常在将客户端调用传递给真是主题对象之前或者之后执行某些操作，而不是单纯返回真实的对象。

动态代理

1）InvocationHandler接口

2）invoke方法

3）Proxy.newProxylnstance（）;

6•命令模式

Command莫式也叫命令模式，是行为设计模式的一种。

Comman模式通过被称为Comman的类封装了对目标对象的调用行为以及调用参数。

命令模式的应用场景

在面向对象的程序设计中，一个对象调用另一个对象，一般情况下的调用过程是：

创建目标对象实例；设置调用参数；调用目标对象的方法。

但在有些情况下有必要使用一个专门的类对这种调用过程加以封装，我们把这种专门的类称作comman（类。

-整个调用过程比较繁杂，或者存在多处这种调用。

这时，使用Comman类对该调用加以封装，便于功能的再利用。

-调用前后需要对调用参数进行某些处理。

-调用前后需要进行某些额外处理，比如日志，缓存，记录历史操作等。

命令模式的结构

invoker

AlsomelimoesKs'eKecutethecommand

Command

+execute（j-

Client

Rpcei

Coneretecommarud

Lpj

MA

+Aclicr（）

aisometimeexeculwcornmard

命令模式的角色和职责

Command

Comman抽象类。

ConcreteCommand

Comman的具体实现类

Receiver

需要被调用的目标对象

Invorker

通过Invorker执行Comman对象。

7•策略模式

Strategy模式也叫策略模式是行为模式之一，它对一系列的算法加以封装，为所有算法定义一个抽象的算法接口，并通过继承该抽象算法接口对所有的算法加以封装和实现，具体的算法选择交由客户端决定（策略）。

Strategy模式主要用来平滑地处理算法的切换。

1）策略模式的结构

0Strategy

0Content

cMrs也勿，StratQgy

9operationO:

void

GGoncreteStrategyA

0ConcneteStrategyB

oalgurithmintsrfaceO:

void

■jalgorithrilnterfaceO:

void

2）策略模式的角色和职责

Strategy:

策略（算法）抽象。

ConcreteStrategy

各种策略（算法）的具体实现。

Context

策略的外部封装类，或者说策略的容器类。

根据不同策略执行不同的行为。

策略由外部环境决定。

3）策略模式的优点：

1.策略模式提供了管理相关的算法族的办法。

策略类的等级结构定义了一个算法或行为族。

恰当使用继承可以把公共的代码移到父类里面，从而避免重复的代码。

2.策略模式提供了可以替换继承关系的办法。

继承可以处理多种算法或行为。

如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。

但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。

决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。

继承使得动态改变算法或行为变得不可能。

3.使用策略模式可以避免使用多重条件转移语句。

多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。

4）策略模式的缺点有：

1.客户端必须知道所有的策略类，并自行决定使用哪一个策略类。

这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。

换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

2.策略模式造成很多的策略类。

有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。

换言之，可以使用享元模式来减少对象的数量。

8.外观模式

Facade模式也叫外观模式，也称门面模式，是由GoF提出的23种设计模式中的一种。

Facade模式为一组具有类似功能的类群，比如类库，子系统等等，提供一个一致的简单的界面。

这个一致的简单的界面被称作facade。

外观模式的结构

Packaigel

-Cilasl.class

doSomethingO

Packaged

<>

doSomelhirigO

6——一、…一…

doSomethingQ

-j^c>

Pack^e&3

doSorriethingQ^

Css1c1=nawClassiQ;

Classic2=newClass2Q；

CIass3c3=newClass3Q：

ddoStuff（c2）;

c3setXfc1getXQ）;returnc3get/Q;

外观模式的角色和职责

Facade

为调用方定义简单的调用接口。

Clients

调用者。

通过Facade接口调用提供某功能的内部类群。

Packages

功能提供者。

指提供功能的类群（模块或子系统）。

9•桥接模式

Bridge模式又叫做桥接模式，是构造型的设计模式之一。

Bridge模式基于

类的最小设计原则，通过使用封装，聚合以及继承等行为来让不同的类承担不同的责任。

它的主要特点是把抽象（abstraction）与行为实现（implementation）分离开来，从而可以保持各部分的独立性以及应对它们的功能扩展。

桥接模式的结构

桥接模式的角色和职责

Client

Bridge模式的使用者

Abstraction

抽象类接口（接口或抽象类）；维护对行为实现（Implementor）的引用

RefinedAbstraction

Abstraction子类

Implementor

行为实现类接口（Abstraction接口定义了基于Implementor接口的更高层

次的操作）

ConcreteImplementor

Implementor子类

10.观察者模式

Observer模式是行为模式之一，它的作用是当一个对象的状态发生变化时，能够自动通知其他关联对象，自动刷新对象状态。

Observer模式提供给关联对象一种同步通信的手段，使某个对象与依赖它的其他对象之间保持状态同步。

观察者模式的结构

观察者模式的角色和职责

Subject（被观察者）

被观察的对象。

当需要被观察的状态发生变化时，需要通知队列中所有观察者对象。

Subject需要维持（添加，删除，通知）一个观察者对象的队列列表。

ConcreteSubject

被观察者的具体实现。

包含一些基本的属性状态及其他操作。

Observer（观察者）

接口或抽象类。

当Subject的状态发生变化时，Observer对象将通过一个callback函数得到通知。

ConcreteObserver

观察者的具体实现。

得到通知后将完成一些具体的业务逻辑处理。

观察者模式的典型应用

-侦听事件驱动程序设计中的外部事件

-侦听/监视某个对象的状态变化

-发布者/订阅者（publisher/subscriber）模型中，当一个外部事件（新的产品，

消息的出现等等）被触发时，通知邮件列表中的订阅者；