JAVA设计模式之创建模式

第一篇：JAVA设计模式之创建模式

设计模式之Builder

Builder模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到.为何使用?

是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件.因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.如何使用?

首先假设一个复杂对象是由多个部件组成的,Builder模式是把复杂对象的创建和部件的创建分别开来,分别用Builder类和Director类来表示.首先,需要一个接口,它定义如何创建复杂对象的各个部件: public interface Builder {

//创建部件A 比如创建汽车车轮

void buildPartA();

//创建部件B 比如创建汽车方向盘

void buildPartB();

//创建部件C 比如创建汽车发动机

void buildPartC();

//返回最后组装成品结果(返回最后装配好的汽车)

//成品的组装过程不在这里进行,而是转移到下面的Director类中进行.//从而实现了解耦过程和部件

Product getResult();} 用Director构建最后的复杂对象,而在上面Builder接口中封装的是如何创建一个个部件(复杂对象是由这些部件组成的),也就是说Director的内容是如何将部件最后组装成成品: public class Director {

private Builder builder;

public Director(Builder builder){

this.builder = builder;} // 将部件partA partB partC最后组成复杂对象 //这里是将车轮 方向盘和发动机组装成汽车的过程 public void construct(){

builder.buildPartA();

builder.buildPartB();

builder.buildPartC();

} } Builder的具体实现ConcreteBuilder: 通过具体完成接口Builder来构建或装配产品的部件;定义并明确它所要创建的是什么具体东西;提供一个可以重新获取产品的接口: public class ConcreteBuilder implements Builder {

Part partA, partB, partC;public void buildPartA(){

//这里是具体如何构建partA的代码

};public void buildPartB(){

//这里是具体如何构建partB的代码 };public void buildPartC(){

//这里是具体如何构建partB的代码 };public Product getResult(){

//返回最后组装成品结果 };} 复杂对象:产品Product: public interface Product { } 复杂对象的部件: public interface Part { }

我们看看如何调用Builder模式: ConcreteBuilder builder = new ConcreteBuilder();Director director = new Director(builder);

director.construct();Product product = builder.getResult();Builder模式的应用

在Java实际使用中,我们经常用到“池”(Pool)的概念,当资源提供者无法提供足够的资源,并且这些资源需要被很多用户反复共享时,就需要使用池.“池”实际是一段内存,当池中有一些复杂的资源的“断肢”(比如数据库的连接池,也许有时一个连接会中断),如果循环再利用这些“断肢”,将提高内存使用效率,提高池的性能.修改Builder模式中Director类使之能诊断“断肢”断在哪个部件上,再修复这个部件.设计模式之Factory

定义:提供创建对象的接口.为何使用?

工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。

为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A()工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。我们以类Sample为例，如果我们要创建Sample的实例对象: Sample sample=new Sample();可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成: Sample sample=new Sample(参数);但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重整）。为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于Java面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。

在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample.我们要实例化他们时,如下: Sample mysample=new MySample();Sample hissample=new HisSample();随着项目的深入,Sample可能还会“生出很多儿子出来”, 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.工厂方法

你会建立一个专门生产Sample实例的工厂: public class Factory{

public static Sample creator(int which){

//getClass 产生Sample 一般可使用动态类装载装入类。if(which==1)

return new SampleA();else if(which==2)

return new SampleB();

} } 那么在你的程序中,如果要实例化Sample时.就使用 Sample sampleA=Factory.creator(1);这样,在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻:就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可能性就越少.好象我们从编程序中也能悟出人生道理?呵呵.使用工厂方法 要注意几个角色，首先你要定义产品接口，如上面的Sample,产品接口下有Sample接口的实现类,如SampleA,其次要有一个factory类，用来生成产品Sample，如下图，最右边是生产的对象Sample：

进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类concreteFactory了。抽象工厂

工厂模式中有: 工厂方法(Factory Method)抽象工厂(Abstract Factory).这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.这里假设：Sample有两个concrete类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和SampleB2 那么，我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂: public abstract class Factory{

public abstract Sample creator();

public abstract Sample2 creator(String name);} public class SimpleFactory extends Factory{

public Sample creator(){

.........return new SampleA } public Sample2 creator(String name){

.........return new Sample2A } } public class BombFactory extends Factory{

public Sample creator(){

......return new SampleB } public Sample2 creator(String name){

......return new Sample2B } }

从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2? 抽象工厂还有另外一个关键要点，是因为 SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如：制造工艺比较简单，所以名称叫SimpleFactory。在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用，举例

我们以Jive的ForumFactory为例，这个例子在前面的Singleton模式中我们讨论过，现在再讨论其工厂模式: public abstract class ForumFactory {

private static Object initLock = new Object();

private static String className = “com.jivesoftware.forum.database.DbForumFactory”;

private static ForumFactory factory = null;

public static ForumFactory getInstance(Authorization authorization){

//If no valid authorization passed in, return null.if(authorization == null){

return null;

}

//以下使用了Singleton 单态模式

if(factory == null){

synchronized(initLock){

if(factory == null){

......}

}

} try {

//动态转载类

Class c = Class.forName(className);

factory =(ForumFactory)c.newInstance();} catch(Exception e){

return null;}

//Now, 返回 proxy.用来限制授权对forum的访问

return new ForumFactoryProxy(authorization, factory，factory.getPermissions(authorization));

}

//真正创建forum的方法由继承forumfactory的子类去完成.public abstract Forum createForum(String name, String description)

throws UnauthorizedException, ForumAlreadyExistsException;

....}

因为现在的Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法ForumFactory就提供了提供动态接口: private static String className = “com.jivesoftware.forum.database.DbForumFactory”;你可以使用自己开发的创建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.在上面的一段代码中一共用了三种模式,除了工厂模式外,还有Singleton单态模式,以及proxy模式,proxy模式主要用来授权用户对forum的访问,因为访问forum有两种人:一个是注册用户 一个是游客guest,那么那么相应的权限就不一样,而且这个权限是贯穿整个系统的,因此建立一个proxy,类似网关的概念,可以很好的达到这个效果.看看Java宠物店中的CatalogDAOFactory: public class CatalogDAOFactory {

/**

* 本方法制定一个特别的子类来实现DAO模式。

* 具体子类定义是在J2EE的部署描述器中。

*/

public static CatalogDAO getDAO()throws CatalogDAOSysException {

CatalogDAO catDao = null;

try {

InitialContext ic = new InitialContext();//动态装入CATALOG_DAO_CLASS //可以定义自己的CATALOG_DAO_CLASS，从而在无需变更太多代码 //的前提下，完成系统的巨大变更。

String className =(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);

catDao =(CatalogDAO)Class.forName(className).newInstance();

} catch(NamingException ne){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: NamingException while

getting DAO type : n” + ne.getMessage());

} catch(Exception se){

throw new CatalogDAOSysException(“

CatalogDAOFactory.getDAO: Exception while getting

DAO type : n” + se.getMessage());

}

return catDao;

} } CatalogDAOFactory是典型的工厂方法，catDao是通过动态类装入器className获得CatalogDAOFactory具体实现子类，这个实现子类在Java宠物店是用来操作catalog数据库，用户可以根据数据库的类型不同，定制自己的具体实现子类，将自己的子类名给与CATALOG_DAO_CLASS变量就可以。

由此可见，工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制，只要我们更换一下具体的工厂方法，系统其他地方无需一点变换，就有可能将系统功能进行改头换面的变化。

设计模式之Prototype(原型)

定义: 用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。如何使用? 因为Java中的提供clone()方法来实现对象的克隆(具体了解clone()按这里),所以Prototype模式实现一下子变得很简单.以勺子为例：

public abstract class AbstractSpoon implements Cloneable {

String spoonName;

public void setSpoonName(String spoonName){this.spoonName = spoonName;}

public String getSpoonName(){return this.spoonName;}

public Object clone()

{

Object object = null;

try {

object = super.clone();

} catch(CloneNotSupportedException exception){

System.err.println(“AbstractSpoon is not Cloneable”);

}

return object;

} } 有两个具体实现(ConcretePrototype): public class SoupSpoon extends AbstractSpoon {

public SoupSpoon()

{

setSpoonName(“Soup Spoon”);

} } public class SaladSpoon extends AbstractSpoon {

public SaladSpoon()

{

setSpoonName(“Salad Spoon”);

} } 调用Prototype模式很简单: AbstractSpoon spoon = new SoupSpoon();AbstractSpoon spoon = new SaladSpoon();当然也可以结合工厂模式来创建AbstractSpoon实例。

在Java中Prototype模式变成clone()方法的使用，由于Java的纯洁的面向对象特性，使得在Java中使用设计模式变得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如Interator遍历模式。

设计模式之Singleton(单态)

定义: Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化;这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

另外方面，Singleton也能够被无状态化。提供工具性质的功能，Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。如何使用?

一般Singleton模式通常有几种形式: public class Singleton {

private Singleton(){}

//在自己内部定义自己一个实例，是不是很奇怪？

//注意这是private 只供内部调用

private static Singleton instance = new Singleton();

}

第二种形式: public class Singleton {

private static Singleton instance = null;public static synchronized Singleton getInstance(){

//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次

//使用时生成实例，提高了效率！if(instance==null)

instance＝new Singleton();return instance;} //这里提供了一个供外部访问本class的静态方法，可以直接访问

public static Singleton getInstance(){

return instance;

} }

使用Singleton.getInstance()可以访问单态类。

上面第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。

注意到lazy initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。关于lazy initialization的Singleton有很多涉及double-checked locking(DCL)的讨论，有兴趣者进一步研究。

一般认为第一种形式要更加安全些。使用Singleton注意事项：

有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下：

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。进一步深入可参考：

Double-checked locking and the Singleton pattern When is a singleton not a singleton?

第二篇：Java设计模式学习心得

Java设计模式学习心得

阅读次数: 1584次 发布时间: 2010-04-10 14:52:13发布人: 网络转载

来源: 网络转载

整个设计模式贯穿一个原理:面对介面编程，而不是面对实现，（面向物件编程应该改爲面向介面编程）。目标原则是:降低耦合，增强灵活性。

一、创建模式

1.设计模式之Factory(工厂方法和抽象工厂)

使用工厂模式就象使用new一样频繁.2.设计模式之Prototype(原型)

用原型实例指定创建物件的种类，並且通过拷贝这些原型创建新的物件。

3.设计模式之Builder

汽车由车轮 方向盘 发动机很多部件组成，同时，将这些部件组装成汽车也是一件複杂的工作，Builder模式就是将这两种情况分开进行。

4.设计模式之Singleton(单态)

保證一个类只有一个实例,並提供一个访问它的全局访问点

二、结构模式

1.设计模式之Facade

可扩展的使用JDBC针对不同的资料库编程,Facade提供了一种灵活的实现。

2.设计模式之Proxy

以Jive爲例,剖析代理模式在用户级别授权机制上的应用

3.设计模式之Adapter

使用类再生的两个方式:组合(new)和继承(extends),这个已经在“thinking in java”中提到过。

4.设计模式之Composite

就是将类用树形结构组合成一个单位。你向别人介绍你是某单位，你是单位元元中的一个元素，别人和你做买卖，相当於和单位做买卖。文章中还对Jive再进行了剖析。

5.设计模式之Decorator

Decorator是个油漆工,给你的东东的外表刷上美丽的顔色。

6.设计模式之Bridge

将“牛郎织女”分开(本应在一起,分开他们,形成两个介面),在他们之间搭建一个桥(动态的结合)

7.设计模式之Flyweight

提供Java运行性能,降低小而大量重复的类的开销。

三、行爲模式

1.设计模式之Template

实际上向你介绍了爲什麽要使用Java 抽象类,该模式原理简单,使用很普遍。

2.设计模式之Memento

很简单一个模式,就是在记忆体中保留原来资料的拷贝。

3.设计模式之Observer

介绍如何使用Java API提供的现成Observer

4.设计模式之Chain of Responsibility

各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个。

5.设计模式之Command

什麽是将行爲封装,Command是最好的说明。

6.设计模式之State

状态是编程中经常碰到的实例,将状态物件化,设立状态变换器,便可在状态中轻鬆切换。

7.设计模式之Strategy

不同演算法各自封装,用户端可随意挑选需要的演算法。

8.设计模式之Mediator

Mediator很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以。

9.设计模式之Interpreter

主要用来对语言的分析,应用机会不多。

10.设计模式之Visitor

访问者在进行访问时,完成一系列实质性操作,而且还可以扩展。

11.设计模式之Iterator

这个模式已经被用来遍曆Collection中物件。使用频率很高。在Java中无需专门阐述,在大多数场合也无需自己制造一个Iterator,只要将物件装入Collection中，我们就直接可以使用Iterator模式。

第三篇：java设计模式考试题

一选择题：共10分

1.Open-Close原则的含义是一个软件实体(a)

A.应当对扩展开放，对修改关闭

2.是10道选择题第一题考完了

二 简答题 共10分

1.什么是设计模式？

设计模式是从许多优秀软件系统中总结出的成功的可复用的设计方案。

2.设计模式的四个基本要素是什么，以及他们是什么含义？

名称：

问题：

方案：

效果：含义在书上p1

三 画类图

14画出命令模式的类图，并写出关键的代码？

见书上17页

15.画出迭代器模式的类图，并写出关键的代码？、见书上105页

四写代码学一个关于求职中心，通知求职者的问题

这是一个观察者模式，具体看看书

我的书是第五章的书上例题

2.是一个交通工具营销问题；

应该是外观模式；见书上99页，应该就是个

这是我们学校的考试题，2012年

第四篇：JAVA学习书籍- 设计模式

谈到设计模式很多人多会推荐GOF 的那本，该书在Amzon上是五星级的推荐书籍。不过对于学习java 没多久的、特别是java 初学者，我很不推荐这本书。主要是该书的例子基本都是C++的，很多细节没有讲述得足够清楚。

我给大家推荐的第一本是阎宏博士的《Java 与模式》，它是第一本中国人自己写的关于设计模式的书籍，写的比较有趣，融合了很多中

华民族的文化和观念，例子、类图都比较多，且相对简单！非常不错的入门书籍――又是大块头哦！

其次我推荐Wiley 出版社出版的《Pattern In Java》一套三本，我才看了第一本，好像第二本不怎么样，第三本还不错！

第三本是中文翻译版的关于多线程模式的（很难得的中文翻译版）中国铁道出版社2003 年出版的《Java 多线程设计模式》，将多线程模

式讲得非常浅显，配有大量的图例，每章都有习题，最后有答案！我研究多线程模式就是由它开始的！

第四本，今年出版的Head First 系列的《Head First Design Pattern》，秉承Head First 系列图书的优点，大量的类图、丰富的实例、有趣的注解，值得购买！

其次在J2EE 方向你可以研究阅读Addison Wesley 2002 年出版的《Patterns of Enterprise Application Architecture》，众多大腕的作品，讲企业消息集成的！Sun 提供的《J2EE PATTERNS SL500》也很好！晚了推荐那一本Amzon 4 星半的《Holub on patterns》，大师的作品，提供了，很值得研究的例子，不过对上面四本不是很熟悉的读者，最好不要读它！可能会让你比较累！

我学习设计模式经过一段很曲折的路线，前前后后大约看了20 本，阎宏博士的《Java 与模式》我看了4 遍，还排除我第一次基本没看

懂的看！记得研一时老师给我们讲了GOF 的那本，作为选修课，我和它们计算机系的硕士、博士们一起，到最后一个班40－50 个人，不

超过3 个人明白，我也没有明白任何一点（基础差吧――主要我对C++语言一点都不了解），凭我不伏输的性格，我认为我对java 语言理

解还可以，我就借了《Java 与模式》，结果还是基本没看懂。很有幸的是读研三时，听过了上交大饶若楠老师关于Java OOP 语言的讲座，我懂了组合书籍模式等三种设计模式后，对其它模式有了强烈的兴趣和要征服它的愿望！工作后我买的第一本就是《Java 与模式》，第一遍花了2 个月研究了这个1000 多页的大块头，后来第三遍15 天左右就可以搞定，笔记记了一大本！从此一发不可收拾。

选对书、埋头研究。相信很快就会入门的！

学习Java 语言8 个简单的部分，这只是我们研究Java 语言的开始！这些都懂了充其量一个java 程序员而已，后面的路很长很长！我们

可以继续研究数据库实现的源代码、Servlet 服务器的源代码、RMI、EJB、JNDI、面向方面编程、重构、ANT 工具、Eclipse 工具、Spring

工具、JBoss、JOnAS、Apache Geronimo 等J2EE 服务器！研究了这些你可能会成为一个出色的J2EE Architecture！你可以继续研究剖

析器、编译器、JNODE（java 写的操作系统）

第五篇：设计模式之心得

刚学几天就有一些浅薄的心得了。

在学过的几种设计模式中（目前为止，本人只学过创建性模式），每一种设计模式都会有一种具体的应用场景，每一种场景描述的都是一种需求变化。设计模式就是用来解决这些变化的。

只要客户有新的需求，你的程序就要发生改变，不管你用什么方法，这个改变是避免不了的。关键是你如何是解决这种变化！设计模式就是寻求一种通用的较好的方法来解决这种变化而不是避免这种变化，并不是你应用了设计模式，你的系统就不会发生变化了。

面向对象的编程有三大机制，我个人认为，设计模式很好的利用了其中的“封装与多态”（当然并不是所有的设计模式都是这样的，也不是说继承就没用，继承在三大机制排第一呀，是基本的），比如工厂方法模式和生成器模式。“封装”的意义不仅仅在于封装代码的实现，更重要的是“封装”系统中变化的部分。设计模式回答了怎么样去“封装”这种变化。

在一个系统中，总会有一部分经常发生变化，相对的，也总有一个部分是改变频率较低的，我们可以在某种范围内将其理解为不改变的部分。设计模式要作的事情就是把“变化”的部分封装起来，实现将“变化”的部分与“不变化”的部隔离，这样，“变化”的部分在发生变化时，不会影响到“不改变”的部分。如果你也学过设计模式，那你可能跟我有同感。设计模式解决变化的途径可以概括为两步（纯属个人见解）：一是转移变化，二是转化变化。

首先是“转移变化”。

简单的说就是把A部分的变化转移到B部分，请B去变化，让A不发生变化。在程序中就是将变化从调用者转移到被调用者。比如，你有一个类scene，这个类用于显现一种风格的游戏场景，调用程序实例化这个类并使用它。如果有一天，需求改变了，当前风格的游戏场景颜色太冷了，我需要改变当前场景的颜色。这个时候你要决定，要让谁去发生变化？是让客户调用程序去改变scene类的颜色属性呢，还是让你的类scene发生变化？设计模式回答的是，请scene发生变化，调用者不发生变化。

为什么要这样回答，因为这个时候，你的系统可能已经交付用户了，如果让调用者发生变化，那整个系统都要发生变化。（这里讨论只是一个简单的应用，实际情况中往往没有这里简单。如果实际情况是这么简单的话，设计模式估计就没有用处了。）

然后是“转化变化”。

确定了要改动scene，那要怎么样去改scene呢？直接改吗？当然不行，如果是这样改，那还不如让调用者去设置scene的某个属性呢，反正都要重新部署。那要怎么改？“扩展”，把这种“改变”转化为“扩展”。你不是要另外一种

scene吗？那我重新为你设计一个sence并生成.dll交付你，然后让现有的程序去调用这个scene。当然，这时可能需要调用者稍微的发生一下变化，比如开始调用者是直接调用scene来呈现场景的，现在将其改为根据配置文件来决定要呈现那种scene。但是如果之前你已经考虑到这个问题了，那调用者是不需要发生任何变化的，因为调用者是根据配置来决定所呈现的场景，需求发生弯化，只需要改变配置文件（可能是一个ＸＭＬ），把调用者与新添的scene关联即可，这样一来，“改动”就变为“扩展”，其带来的好处也是显而易见的，这也就是所谓的“开闭”原则。

以上文字完全是本人理解，随着不断的学习，我想这么文章估计要被改好多次，这是一个学习的过程。理解错了、写错了都不要紧，关键是你怎么样去面对这种错误！是拒绝承认错误还是正视错误？这也是设计模式回答的问题。