1.    模式定义... 1

2.    模式介绍... 1

3.    模式特点... 2

4.    与其它模式的关系... 3

5.    参考... 3

1.    模式定义

工厂方法模式 (Factory Method) 是创建模式的一种，也叫虚拟构造子 (Virture Constractor) 模式或多态性工厂 (Polymorphic Factory) 模式。

       工厂方法模式定义一个抽象的对象创建类或接口，将实际的对象创建工作交给子类来实现。

2.    模式介绍

2.1. 简单类图

2.2. 类图对应示例代码

2.2.1. 抽象产品： AbstractProduct

public interface AbstractProduct{

  public void printName();

}

2.2.2. 具体产品： ConcreteProduct1 和 ConcreteProduct2

public class ConcreteProduct1 implements AbstractProduct{

  public void printName(){

    System.out.println(“ConcreteProduct1”);

}

}

public class ConcreteProduct2 implements AbstractProduct{

  public void printName(){

    System.out.println(“ConcreteProduct2”);

}

}

2.2.3. 抽象工厂： AbstractFactory

public interface AbstractFactory {

  public AbstractProduct factoryMethod();

}

2.2.4. 具体工厂： ConcreteFactory1 和 ConcreteFactory2

public class ConcreteFactory1 implements AbstractFactory{

  public AbstractProduct factoryMethod(){

//do something.

return new ConcreteProduct1();

}

}

public class ConcreteFactory2 implements AbstractFactory{

  public AbstractProduct factoryMethod(){

//do something.

return new ConcreteProduct2();

}

}

3.    模式特点

3.1. 开闭原则（优点）

工厂方法模式解决了简单工厂模式的一些缺陷，是在简单工厂模式的基础上发展的。

简单工厂模式把所有的重心放到工厂类上，一旦向系统增加新的产品，就必须修改工厂类，不满足开闭原则；工厂方法模式提供一个抽象的工厂接口，在不同的产品结构上实现不同的产品工厂具体类来创建该层次中的产品，通常一个具体工厂创建一个具体产品。在新增产品的时候，只需要实现新的对应工厂就可以满足需要，是符合开闭原则的。

3.2. 缺点

1. 相比简单工厂模式，工厂方法模式客户端编程复杂，每个产品的创建都需要实例化对应的工厂类。
2. 相对的扩展性，当需要修改产品结构中的对各产品的时候，需要修改各个工厂（当然也可以直接新加入很多新的产品和工厂，但这样不是又增加了很多无用的遗留类吗，而且现实中很可能要修改客户端代码了。），而简单工厂模式仍然只要修改一个工厂类。
3. 现实中常常要使用退化模式，失去多态性。实际设计中经常会有子类新增功能，那么在对应工厂生产该类的时候就需要直接返回该具体类，而不是抽象产品，不然就要向下转型了。

4.    与其它模式的关系

工厂方法模式与模板模式

5.    参考

《 java 设计模式》 阎宏 电子工业出版社

本文是自己关于关键字 final 的一些总结。 final 关键字主要应用在标志和声明类，成员变量和方法为不可变，通过这个基本定义可以扩展到 final 可以限制类和方法的继承关系。

final 变量

final 变量分为简单变量和对象变量。声明 final 的简单变量，表示该变量从初始化后其值（简单变量直接存储值，而不是引用）就不会改变，需要注意的是在使用其他类提供的 public 的 final 简单变量的时候，就算其他类改变了其定义并重新编译，使用的类在重新编译前该值是不会改变的（参考： http://blog.csdn.net/daniel112/archive/2006/10/11/1330255.aspx ）。声明为 final 的对象变量表示一旦初始化其引用不会改变。

final 变量初始化化可以在声明时或构造函数中完成。

final 类

定义为 final 的类表示该类不能被继承，也就是说该类是一个功能设计完成，不在需要扩展的类。同时该成员方法也对应默认标志为 final ，成员变量随定义而定。

final 方法

定义为 final 的方法表示该方法不能被子类覆写（ override ）。

    一， servlet 容器对 url 的匹配过程：

      根据这个规则表，就能很清楚的知道 servlet 的匹配过程，所以定义 servlet 的时候也要考虑 url-pattern 的写法，以免出错。

      对于 filter ，不会像 servlet 那样只匹配一个 servlet ，因为 filter 的集合是一个链，所以只会有处理的顺序不同，而不会出现只选择一个 filter 。 Filter 的处理顺序和 filter-mapping 在 web.xml 中定义的顺序相同。

    二，url-pattern 详解

         在 web.xml 文件中，以下语法用于定义映射：

l  以 ”/’ 开头和以 ”/*” 结尾的是用来做路径映射的。

l  以前缀 ”*.” 开头的是用来做扩展映射的。

l  “/” 是用来定义 default servlet 映射的。

l  剩下的都是用来定义详细映射的。比如： /aa/bb/cc.action

所以，为什么定义 ”/*.action” 这样一个看起来很正常的匹配会错？因为这个匹配即属于路径映射，也属于扩展映射，导致容器无法判断。

1. 需要动态的扩展一个类，这些扩展也可以动态的撤销，并保持原有类的静态定义的情况。
2. 需要增加由一些基本功能排列组合贰产生的非常强大的功能，并使继承关系变得不实现，典型的Wrapper应用。

大多数情况下，装饰模式的实现都比上面定义中给出的示意性实现要简单。对模式进行简化时需要注意以下的情况：

（1）一个装饰类的接口必须与被装饰类的接口相容。

（2）尽量保持Component作为一个"轻"类，不要把太多的逻辑和状态放在Component类里。

（3）如果只有一个ConcreteComponent类而没有抽象的Component类（接口），那么Decorator类经常可以是ConcreteComponent的一个子类。

（4）如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。

透明的装饰模式

所谓透明是指对客户端程序员来说是针对接口编程，而不是具体的继承或实现类。引用彦博士的《java与模式》的说法是：“必须永远把孙悟空的所有变化都当成孙悟空来对待，而如果把老孙变成的雀儿当成雀儿，而不是老孙，那就被老孙骗了，而这是不应当发生的。”

下面的做法是对的：

半透明的装饰模式

然而，纯粹的装饰模式很难找到。装饰模式的用意是在不改变接口的前提下，增强所考虑的类的性能。在增强性能的时候，往往需要建立新的公开的方法。即 便是在孙大圣的系统里，也需要新的方法。比如齐天大圣类并没有飞行的能力，而雀儿有。这就意味着雀儿应当有一个新的fly()方法。

这就导致了大多数的装饰模式的实现都是"半透明"（semi-transparent）的，而不是完全"透明"的。换言之，允许装饰模式改变接口， 增加新的方法。即声明ConcreteDecorator类型的变量，从而可以调用ConcreteDecorator类中才有的方法：

齐天大圣接口根本没有fly()这个方法，而雀儿接口里有这个方法。

参考：

《java与模式》

google搜索："java decorator"