布莱克洛

功能分解可以按照1，2，3，3a,3b,3c,4,5来分类，分类最好按照对象进行，直到方便管理为止需求总是完整，清晰，容易理解->这是句屁话责任重新组织是设计模式用来简化问题，抽象细节的要点，最经典的就是教师通知学生上课开发过程中的三个视角：概念（注重功能需求，对象是责任），规格（注重接口，最好的视角，对象是调用），实现（注重代码，最常用的视角，对象是代码）聚集类似于飞机场和飞机的

Bridge模式意图：将一组实现部分从另一组使用它们的对象中分离出来。问题：一个抽象类的派生类必须使用多种实现部分，但又并不能引起数量的爆炸。解决方案：为所有的实现部分定义一个接口，让抽象类的所有派生类使用这个接口。参与者与协作者：Abstraction为正在实现的对象定义接口。Implementor为特定的实现部分类定义接口。Abstraction的派生类使用Implementor的派生

Adapter模式意图：将一个无法控制的现有对象与一个特定接口相匹配。问题：一个系统哦功能拥有正确的数据和行为，但接口却是错误的。典型用途：你必须把某些东西实现为我们定义或者已经拥有的抽象类的派生接口。参与者和协作者：Adapter对Adaptee的接口进行适配，使它与Target（Adapter派生自它）相匹配。让Client把Adaptee当作Target的一个类型来使用它。效果：A

Memento 用的很多，就是把状态简单保存起来，以后再恢复参考：http://www.jdon.com/designpatterns/memento.htm放段代码/* * To change this template, choose Tools | Templates * and open the template in the editor. */package

参考jdon：http://www.jdon.com/designpatterns/mediator.htmMediator其实就类似于关系型数据库中的ManyToMany关系，通过中间对象Mediator连接这里可以举一个多对多聊天的例子:

这个模式非常有用，可以执行一些权限检查，资源调配的工作！参考jdon:http://www.jdon.com/designpatterns/designpattern_proxy.htm这里面还有个例子非常好，用到了singleton，factory，proxy多个模式，很值得学习

参考jdon:http://www.jdon.com/designpatterns/flyweight.htmFlyWeight其实就是在Factory加入了一个Shared Pool来减少资源浪费

参考jdon：http://www.jdon.com/designpatterns/composite.htmComposite就是一种树形结构，在接口类里要提供一个游标iterator供遍历子类对象用的挺多的，这个也需要自己尝试的写一个例子：

主要是对文本的解析这里有两个例子：http://www.oodesign.com/interpreter-pattern.html用的很少，但思想很不错，一定要自己动手写一个

意图：让你可以使用不同的业务规则或算法——取决于它们出现的场景。问题：需要根据发出请求的客户或被处理的数据对算法作出选择。如果你只是拥有一些不发生变化的算法，你就不需要Strategy模式。解决方案：将算法的选择和算法的实现想分离。让客户可以基于场景做出选择。参与者和协作者： 1.Strategy规定如何使用不同的算法。 2.ConcreteStrategy实现这些不同的算法。 3.C

参考jdon：http://www.jdon.com/designpatterns/designpattern_State.htm我觉得state应该用的很多，许多动作都是依赖于状态的说说我理解的几个要点：1.state主要用在需要多个状态开关切换，且有多种切换方式2.对象的操作决定于状态3.将状态和状态相关（甚至是状态切换的操作）都放到state中4.context负责操

本文出处：http://blog.csdn.net/blacklaw0/article/details/8870600我主要参考的是则两个网站jdon：国内大牛 http://www.jdon.comsourcemaking:很轻松的一个网站，它信奉  Just smile before learing serious things!http://www.sourcemak

参考jdon：http://www.jdon.com/designpatterns/visitor.htm访问者模式最重要的一点就是将判断语句用接口实现了，推迟到visitable中，由子类决定visitor调用那个方法

专家系统是一个特殊的计算机系统，它使用人类专家的规则自动做出决策。创建专家系统包括两个步骤。首先，获取专家用于做出决策，完成任务的规则，并将这些规则建模。第二，在计算机中实现这些规则；这个步骤通常会用到一些商用专家系统工具。对于分析者来说，第一个步骤的任务困难得多

Observer模式意图：在对象之间定义一种一对多的依赖关系，这样当一个对象的状态改变时，所有依赖与它的对象都将得到通知并自动更新。问题：当某个事件发生时，你需要向一系列对象发出通知，而这个对象的列表是不断变化的。解决方案：Observer将监视某个事件的责任委托给一个中心对象：Subject。参与者和协作者：Subject知道自己的Observer，因为Observer在Subject上

Singleton 模式意图：你希望只拥有一个对象，但不用全局对象来控制对象的实例化。问题：几个不同的客户对象需要引用同样的对象，你希望确保自己拥有这种对象不超过一个。解决方案：保证一个实例。参与者与协作者：客户对象只能通过getInstance 方法创建Singleton的实例。效果:客户对象不需要关心是否已经有Singleton的实例存在。这可以在Singleton内部得到控制。实

Template Method模式意图：定义一个操作中的骨架，而将一些步骤延迟到子类中。Template Method模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。问题：需要遵循一个过程或一系列步骤，它们在某个具体层次上保持一致，但单个步骤在更详细的层次上可能有不同的实现。解决方案：允许定义不同的子步骤，同时维护基本过程的一致性。参与者和协作者：Template M

意图：为一个对象动态连接附加的职责。问题：你需要使用的对象执行你要求的基本功能。但是，你可能需要为这个对象添加某些功能。这些附加功能可能发生在对象的基础功能之前或之后。请注意，Java基础类在I/O处理中广泛使用了Decorator模式。解决方案：允许扩展一个对象的功能，而不必借助于子类型化。参与者与协作者：Decorator对象为ConcreteComponent添加功能。有时候Concr

Facade模式意图：希望简化现有系统的使用方法。你需要定义自己的接口。问题：只需要使用一个复杂系统的子集。或者，需要用一种特殊的方式与系统交互。解决方案：Facade想客户展现使用现有系统的一个新的接口。参与者与协作者：向客户展现一个定制的接口，让客户更容易地使用现有系统。效果：Facade模式简化了对所需子系统的使用。但是，由于Facade并不完整，因此某些功能对于客户可能是不可用的

Abstract Factor模式意图：你需要为特定的客户（或情况）提供特定系列的对象。问题：一系列相关的对象的创建过程。提供一种方法保持“如何在客户对象外部执行对象实例化”的规则，客户对象将使用这些实例化出来的对象。参与者和协作者：Abstract Fctactory为“如何创建需要的每个系列的对象”定义接口。典型情况下，每个系列都独立拥有自己的ConcreteFactroy，通过它被实例

Factory Method意图：定义 一个用于创建对象的接口，让子类决定实例化那一个类。将实例化延迟到其子类问题：一个类需要实例化另一个类的派生类，但不知道具体的是哪个派生类。Factory Method允许让派生类来做出决定。解决意图：一个派生类对“实例话那个类，如何实例化”的问题做出决定。参与者与协作者：Product是Factory Method模式创建的对象的类型接口。Creat

原型模式prototype，java里面就是用clone实现的，对prototype拷贝获取备份参考http://www.jdon.com/designpatterns/prototype.htm

建造者模式Builder DPhttp://www.jdon.com/designpatterns/builder.htmhttp://sourcemaking.com/design_patterns/builder

参考jdon:http://www.jdon.com/designpatterns/command.htm在对象与调用者之间通过collection来模糊对象，降低耦合，用接口实现对对象的管理这里用的是list来储存command队列