HeadFirst设计模式流程图个人总结.doc

Gof设计模式的UML 类别图：(1) Simple factory模式 :(2) Abstract factory模式 :(3) Builder模式：注：您想要建立一个迷宫产生程式，迷宫使用二维阵列来定义，0表示道路，1表示墙，2表示宝物，根据所定义的二维迷宫阵列，您想要程式自动产生各种不同材质的迷宫，例如砖墙迷宫，钻石迷宫等等。(4) Factory Method模式：文件编辑器(5) Prototype模式：您从图书馆的期刊从发现了几篇您感兴趣的文章，由于这是图书馆的书，您不可以直接在书中作记号或写字，所以您将当中您所感兴趣的几个主题影印出来，这下子您就可在影印的文章上画记重点。Prototype模式的作用有些类似上面的描述，您在父类别中定义一个clone()方法，而在子类别中重新定义它，当客户端对于所产生的物件有兴趣并想加以利用，而您又不想破坏原来的物件，您可以产生一个物件的复本给它。Prototype具有展示的意味，就像是展览会上的原型车款，当您对某个车款感兴趣时，您可以购买相同款示的车，而不是车展上的车。Java中的clone()方法是继承自Object(6) Singleton单例模式：实现工具类CommonUtil的Singleton模式： private static CommonUtil commonUtil = null;public static CommonUtil getInstance() /加同步锁，防止多线程情况下同时进入申请实例 synchronized(commonUtilLock) if(commonUtil = null) /创建工具类的单实例 commonUtil = new CommonUtil(); /返回实例 return commonUtil; public class Singleton /单线程的情况下单例模式private static Singleton instance = null;private Singleton() / .public static Singleton getInstance() if (instance = null) instance = new Singleton();return instance;public class Singleton /多线程的情况下单例模式加互斥锁private static Singleton instance = null;private Singleton()synchronized static public Singleton getInstance() if (instance = null) instance = new Singleton();return instance;Double-check Locking的模式:public class Singleton private static Singleton instance = null;private Singleton()public static Singleton getInstance() if (instance = null)synchronized(Singleton.class)if(instance = null) instance = new Singleton();return instance;Reflection机制实现单例模式 :public class Singleton private static Singleton instance = null;private Singleton() / .public static Singleton getInstance() if (instance = null) / getEnv表示环境变数String style = getEnv(style);try instance = (Singleton)Class.forName(style).newInstance();catch(Exception e) System.out.println(Sorry! No such class defined!);return instance;/ .Registry of Singleton方法：import java.util.*;public class Singleton / 注册表，用于注册子类别物件private static Map registry = new HashMap();private static Singleton instance;public static void register(String name, Singleton singleton) registry.put(name, singleton);public static Singleton getInstance() if (instance = null) / getEnv表示取得环境变数String style = getEnv(style);instance = lookup(style);return instance;protected static Singleton lookup(String name) return (Singleton) registry.get(name); (7) Adapter模式 :Class Adapter模式 :C+ :Java :C+中多重继承Java不能多重继承，但Java中可以使用接口（interface）来达到多重继承的效果(8) Bridge模式 ：目的：“将抽象部份与它的实现部份分离，使它们都可以独立地变化。” Bridge模式的 UML 类别结构图如下：(9) Composite模式 ：如果以绘图为例的话，一个文字是一个绘图元件，一个线段是一个绘图元件，而一个长方形也是一个绘图元件，这些绘图元件可以组成一个图片，如果将这个图片也视作一个绘图元件，则这么递归绘图下去，就可以组合成一个较大的、复杂的图形元件，这样的目的可以使用Composite模式来解决。以 UML 来表示上面这个例子的结构：组合模式的UML结构图如下所示：除了绘图元件之外，一些具有层次性或组合性的物件也可以使用Composite模式，像是电路元件、设备元件等等，使用Composite模式可以大大减低这些元件设计的复杂度。(10) Decorator模式：解析：动态的为JTextArea加入功能的方法，我们可以使用Decorator模式来组织结构，您可以动态的为一个物件加入一些功能（像是为 JTextArea加上卷轴），而又不用修改JTextArea的功能。对JTextArea来说，JScrollPane就好像是一个卷轴外框，直接套在JTextArea上作装饰，就好比您在照片上加上一个相框的意思。Decorator模式的 UML 结构图如下所示：依赖度 耦合度(11) Faade(外观)模式：Faade实例UML图：如上图所示的，您的应用程式本身将不直接依赖于您的元件，而是依赖一个介面，当您想要更改某个商务行为的实作时，只要修改实现的类就可以了，应用程式本身不用作任何修改。Facade模式的结构如下：Facade模式隐藏了各个元件之间的合作行为，以及元件本身的操作与设定细节，固而必失去了一些直接操作元件的方便性，所以对于喜欢追求与操作细节的程式设计人员而言，不会很喜欢透过Facade来操作背后的元件，所以您的Facade介面设计，通常要在元件依赖性及元件的支接操作性之间作个平衡。(12) Flyweight模式：特轻量级类别 模式图如下：(13) Proxy模式 ：目的给定为：为其它的物件提供一种代理，以控制对这个物件的访问。由这句话所延伸出来的意思是，根据您的目的不同，您的代理物件将负有不同的责任，因为产生多种不同的代理情况。Proxy模式的 UML 结构图如下所示：Chain of Responsibility的概念在 Gof 的书中给定Chain of Responsibility目的为：使多个物件都有机会处理请求，以避免请求的发送者与接收者之间的耦合关系，将这些物件组合为一个链，并沿着这个链传递该请求，直到有物件处理它为止。UML 结构图如下所示：(14) Command模式：Java的Swing视窗程式，WEB MVC Framework使用的就是Command模式在这样的例子中，Container就好比Command模式中Client的角色，而前端 Controller（例如JSP技术中通常会采用的Dispatcher Servlet）就相当于Invoker，而Action则相当于ICommand的角色，至于Receiver角色就是您封装在Action中执行的物件了。这种将请求封装起来的模式，就是Command模式，它将请求后的实作部份留待使用者实作。Command模式的UML类别图如下所示：(15) Interpreter模式：对于一个具有层次节点关系的问题来说，如果您要剖析每一个节点，您可以使用Interpreter模式，直译器模式有些类似演算法中的个别击破方式，对每一个父节点我们剖析出其子节点组合，然而交给子节点剖析物件继续剖析，直到剖析至终端节点为止。(16) Iterator模式：(17) Mediator模式：意思是中介者、调节者、传递物高聚合性简单的说，Mediator设计有与组件沟通的介面，介面中封装了与其它组件互动细节，组件与组件之间不用知道彼此的存在，它们只要与Mediator沟通就好了，利用这种方式，可以切开组件与组件之间的耦合。基本上Mediator模式在使用时的弹性很大，由Sequence Diagram理解概念，会比从Class Diagram了解结构来得重要，不过在ClassDiagram中可以注意的是类别的名称，Colleague是同事的意思，将一群共事的元件视为一群共同合作的同事，为了使同事之间的活动独立，并使得团队合作的交互更具弹性，需要一个Mediator来协调同事之间的业务行为。(18) Memento模式：(19) Observer 模式：在Observer模式中的主角为主题（subject）与观察者（observer），观察者订阅它感兴趣的主题，一个主题可以被多个观察者订阅，当主题的状态发生变化时，它必须通知（notify）所有订阅它的观察者，观察者检视主题的状态变化，并作出对应的动作，所以Observer 模式也称之为Publish-Subscribe模式。Subject类中有一个notify()方法，通常是在Subject的状态发生改变时呼叫它，notify()中会呼叫 Observer的update()方法，通常会先取得Subject的新状态，然后更新Observer的显示或行为。这个过程我们可以透过 Sequence Diagram来表达：(20) State模式 :(1) 状态变化并不是流水式的变化(2) 让物件控制自己的状态转换与所应表现的行为State模式的UML结构图如下：Abstract类 虚函数 接口(21) Strategy模式： 例子：微波炉调控Strategy模式的UML类别结构图如下：从行为上来说，State 模式与Strategy 模式是蛮相近的。State 模式：看当前是什么状态，就采取什么动作。Strategy模式：看需求（情境）是什么，采用适当的策略。不过两者虽相似，应用的场合稍有不同，State 模式中有一个重点在于设定状态变化，就像 Gof 例子中举的TCP连线；Strategy 策略模式则是直接采用适当的策略的感觉，例如Gof中说的，采用适当的演算法来作正文换行。(22) Template Method模式：对于一些程式而言，我们希望规定一些处理的步骤、流程或骨架。抽象类别与接口的差别之一，也正在于抽象类别可以先实现其中一些方法，而接口则是完全仅规定接口，使用Template Method模式就可以看出两者之间在应用上的一个差别。Factory Method 模式将实际要创建的物件推迟至子类中决定，而Template Method模式则是将流程框架的实作留待子类来解决，事实上在这个例子中，您也可以将 createDocument() 看作是Template Method 模式中的一个方法，从物件创建的角度来看它是Factory Method，而从流程框架的角度来看，它则是Template Method模式的一个方法实作。(23) Visitor 模式：在Java中所有的物件都继承自Object物件，这样作的优点之一，就是使得一些集合物件的资料结构容易管理，例如，您可以将任何型态的物件放入Vector中。将来的扩充性从物件自身的角度来想好了，物件在一个个的房子中，物件说：“不要在房子外费尽心思判断了，即然您不知道我是谁，那么您就进来访问我好了，我告诉您我是谁，这么一来您就知道如何操作我了！”可以利用reflection来改进使用访问者模式时的弹性(24) Guarded Suspension模式： Client requestQueue Server考虑这么一个伺服器，它可以处理来自多个客户端的服务请求（Request），为了不丢失客户的请求，它要维持一个缓冲区，客户的请求会先储存至缓冲区中，而伺服器会从缓冲区中取出请求并执行，如果缓冲区中没有请求，则伺服器就等待，直到被通知有新的请求存入缓冲区中，伺服器再度进行请求的执行。Guarded Suspension模式并不限制缓冲区的长度Synchronized (25) Producer Consumer模式 ： 生产者 消费者Producer Consumer模式假设所生产的产品放置在一个长度有限制的缓冲区（就像是一个产品桌，它可以摆放的空间是有限的），如果缓冲区满了，则生产者必须停止继续将产品放到缓冲区中，直到消费者取走了产品而有了空间，而如果缓冲区中没有产品，当然消费者必须等待，直到有新的产品放到缓冲区中。(26) Worker Thread模式：在Request的管理上像是Producer Consumer 模式，在Request的行为上像是Command 模式。Producer Consumer模式专注于Product的生产与消费，至于Product被消费时是作何处理，则不在它的讨论范围之中如果您的Product是一个Request，消费者取得Request之后，执行Request中指定的请求方法，也就是使用Command模式，并且您的Request缓冲区还管理了Consumer，就有Worker Thread模式的意思了。在Sequence Diagram上，可以看出Worker Thread同时展现了Producer Consumer模式与Command模式：就行为上，Worker Thread 就是有请求来了就作，如果没有请求，则所有的Worker Thread 就等待，直到有新的工作进来而通知它们，取得请求的Worker Thread 要作的工作，就直接定义在 execute()中。(27) Thread-Per-Message模式：Thread-Per-Message模式是在某个请求发生时，新增一个执行绪来执行该请求，而主执行绪继续往下执行，除了上面的载入档案例子之外，像是进行搜寻、字串转换之类需要一些时间来执行的工作时，使用Thread-Per-Message模式都可以提高主执行绪（界面）的回应性。(28) Future模式：Future模式可以简