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

Class.forName(style).newInstance();
}
catch(Exception e) {
System.out.println("Sorry! No such class defined!");
}
}
return instance;
}
// ....
}
Registry of Singleton方法：
Java不能多重继承，但Java中可以使用接口（interface）来达到多重继承的效果
(8)Bridge模式：目的：“将抽象部份与它的实现部份分离，使它们都可以独立地变化。”
Bridge模式的UML类别结构图如下：
(9)Composite模式：
如果以绘图为例的话，一个文字是一个绘图元件，一个线段是一个绘图元件，而一个长方形也是一个绘图元件，这些绘图元件可以组成一个图片，如果将这个图片也视作一个绘图元件，则这么递归绘图下去，就可以组合成一个较大的、复杂的图形元件，这样的目的可以使用Composite模式来解决。
(16)Iterator模式：
(17)Mediator模式：意思是中介者、调节者、传递物
高聚合性
简单的说，Mediator设计有与组件沟通的介面，介面中封装了与其它组件互动细节，组件与组件之间不用知道彼此的存在，它们只要与Mediator沟通就好了，利用这种方式，可以切开组件与组件之间的耦合。
基本上Mediator模式在使用时的弹性很大，由Sequence Diagram理解概念，会比从Class Diagram了解结构来得重要，不过在ClassDiagram中可以注意的是类别的名称，Colleague是同事的意思，将一群共事的元件视为一群共同合作的同事，为了使同事之间的活动独立，并使得团队合作的交互更具弹性，需要一个Mediator来协调同事之间的业务行为。
以UML来表示上面这个例子的结构：
组合模式的UML结构图如下所示：
除了绘图元件之外，一些具有层次性或组合性的物件也可以使用Composite模式，像是电路元件、设备元件等等，使用Composite模式可以大大减低这些元件设计的复杂度。
(10)Decorator模式：
解析：动态的为JTextArea加入功能的方法，我们可以使用Decorator模式来组织结构，您可以动态的为一个物件加入一些功能（像是为JTextArea加上卷轴），而又不用修改JTextArea的功能。对JTextArea来说，JScrollPane就好像是一个卷轴外框，直接套在JTextArea上作装饰，就好比您在照片上加上一个相框的意思。
private Singleton(){}
synchronized static public Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
Double-check Locking的模式:
returncommonUtil;
}
}
public class Singleton {//单线程的情况下单例模式
private static Singleton instance = null;
private Singleton() {
// ....
}
public static Singleton getInstance() {
Facade模式隐藏了各个元件之间的合作行为，以及元件本身的操作与设定细节，固而必失去了一些直接操作元件的方便性，所以对于喜欢追求与操作细节的程式设计人员而言，不会很喜欢透过Facade来操作背后的元件，所以您的Facade介面设计，通常要在元件依赖性及元件的支接操作性之间作个平衡。
(12)Flyweight模式：特轻量级类别模式图如下：
Gof设计模式的UML类别图：
(1)Simple factory模式:
(2)Abstract factory模式:
(3)Builder模式：
注：您想要建立一个迷宫产生程式，迷宫使用二维阵列来定义，0表示道路，1表示墙，2表示宝物，根据所定义的二维迷宫阵列，您想要程式自动产生各种不同材质的迷宫，例如砖墙迷宫，钻石迷宫等等。
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;
}
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)
这种将请求封装起来的模式，就是Command模式，它将请求后的实作部份留待使用者实作。
Command模式的UML类别图如下所示：
(15)Interpreter模式：
对于一个具有层次节点关系的问题来说，如果您要剖析每一个节点，您可以使用Interpreter模式，直译器模式有些类似演算法中的个别击破方式，对每一个父节点我们剖析出其子节点组合，然而交给子节点剖析物件继续剖析，直到剖析至终端节点为止。
(18)Memento模式：
(19)Observer模式：
在Observer模式中的主角为主题（subject）与观察者（observer），观察者订阅它感兴趣的主题，一个主题可以被多个观察者订阅，当主题的状态发生变化时，它必须通知（notify）所有订阅它的观察者，观察者检视主题的状态变化，并作出对应的动作，所以Observer模式也称之为Publish-Subscribe模式。
(13)Proxy模式：
目的给定为：为其它的物件提供一种代理，以控制对这个物件的访问。由这句话所延伸出来的意思是，根据您的目的不同，您的代理物件将负有不同的责任，因为产生多种不同的代理情况。
Proxy模式的UML结构图如下所示：
Chain of Responsibility的概念
在Gof的书中给定Chain of Responsibility目的为：使多个物件都有机会处理请求，以避免请求的发送者与接收者之间的耦合关系，将这些物件组合为一个链，并沿着这个链传递该请求，直到有物件处理它为止。
(1)状态变化并不是流水式的变化
(2)让物件控制自己的状态转换与所应表现的行为
State模式的UML结构图如下：
Abstract类虚函数接口
(21)Strategy模式：例子：微波炉调控
Strategy模式的UML类别结构图如下：
从行为上来说，State模式与Strategy模式是蛮相近的。
State模式：看当前是什么状态，就采取什么动作。
Subject类中有一个notify()方法，通常是在Subject的状态发生改变时呼叫它，notify()中会呼叫Observer的update()方法，通常会先取得Subject的新状态，然后更新Observer的显示或行为。这个过程我们可以透过Sequence Diagram来表达：
(20)State模式:
publicstaticCommonUtil getInstance(){
//加同步锁，防止多线程情况下同时进入申请实例
synchronized(commonUtilLock){
if(commonUtil==null){
//创建工具类的单实例
commonUtil=newCommonUtil();
}
//返回实例
}
returninstance;
}
protectedstaticSingleton lookup(String name) {
return(SBiblioteka ngleton)registry.get(name);
}
}
—>
(7)Adapter模式:
Class Adapter模式 :
C++:
Java:
C++中多重继承
importjava.util.*;
publicclassSingleton {
//注册表，用于注册子类别物件
privatestaticMapregistry=newHashMap();
privatestaticSingletoninstance;
publicstaticvoidregister(String name, Singleton singleton) {
Prototype具有展示的意味，就像是展览会上的原型车款，当您对某个车款感兴趣时，您可以购买相同款示的车，而不是车展上的车。
Java中的clone()方法是继承自Object
(6)Singleton单例模式：
实现工具类CommonUtil的Singleton模式：
privatestaticCommonUtil commonUtil = null;