“学习OO好榜样”之创建类模式

周末再翻《Java与模式》，说说对创建类模式的一点理解。大家交流。

创建类模式，我主要关注的是Simple Factory、Factory Method、Builder这几个。
当然，其他一些模式可能更加常用，比如Singleton、Prototype，但比较简单，不涉及整体脉络，此处略去不述。

首先，说说Simple Factory。
创建类模式，都是对实例创建过程的封装。
Simple Factory，是最容易想到的封装方式，Client无需知道某类的instance是怎么弄出来的，直接跟工厂要实例就行了，而且是静态方法，调用起来也方便。此时，工厂(书中叫做Creator)挑起重担，何时创建什么实例、如何创建全部由他来操办。
当工厂的担子越来越重时，比如，产品种类猛增、各个产品实例的创建过程都比较复杂、判断创建何种产品实例的逻辑也越来越复杂，工厂的改动日趋频繁，而且严重地违反了Open-Close法则，不同产品类的创建代码互相影响，这就说明对变化的封装没有达到应用的效果，产品A的变化影响到了产品B。对Simple Factory的优化产生了Factory Method。

Factory Method。
不同产品的创建过程既然都有着各不相同的单独逻辑，很容易想到把这些各自繁衍的变化封装起来，于是，不同的产品由配套的Creator来创建实例。此时，系统更加复合Open-Cloase法则，增加了新产品，同时增加相应的Creator，他们都位于继承结构的叶子端，不影响枝干和其他兄弟叶子。
但，此时，Client就需要知道哪个产品是使用哪个Creator来获得实例的了。让Client知道得多了，并不一定是坏事，个人感觉这里的情况是更加符合接口隔离原则，获得了该原则带来的优势。

Abstract Factory。
用于产品系列，个人不是很喜欢这个模式。当然也欢迎大家讨论。该模式此处不述。

Builder。
如果某类的实例创建需要固定的几个步骤(我理解为几道工序或者几个零件)，想到将生产、组装过程分开(脱开耦合、增加可插入性)，再参考Template Method模式的思路，就产生了Builder模式。

再罗索一遍，创建类模式都是对实例创建过程的封装，不同模式适用于不同情况，使用得是否得当我觉得就是看对变化的封装做得好不好。

AbstractFacotry和FactoryMethod有不同的适用方面。
这里我介绍一下 AbstractFacotry。
对于FactoryMethod，所有的商品都是同一种东西，实现一个身份接口。这时统计具体商品只是一条直线。
但是，这并不能满足所有的情况，比如，对于一个C/S结构的控件来说，我们可以把它们分为文本框、下拉框、滚动条等等，这是按照使用分类；但是，我们还可以按照操作系统分类，比如Windows的各种控件、Unix的各种组件。
这样，我用代码写一下看看。
public interface 文本框{}
public interface 下拉框{}
public class Windos文本框{...}
public class Windos下拉框{...}
public class Unix文本框{...}
public class Unix下拉框{...}
public abstract class AbstractFactory{
  public abstract 下拉框 get下拉框();
  public abstract 文本框 get文本框();
}
public class WindowsFactory extends AbstractFactory{
  public 下拉框 get下拉框(){ return new Windows下拉框();}
  public 文本框 get文本框(){ return new Windows文本框();}
}
同理public class UnixFactory extends AbstractFactory{...}
因此，可以看到，对FactroyMethod的具体商品的管理是一条直线，而对AbstractFacotry的具体商品的管理是一个二维表。
但是，需要指出的是AbstractFactory是一种倾斜的“开闭”，即，如果增加一种操作系统，非常容易，可以不修改原来的代码，但是如果每种操作系统都要增加一种控件，就需要所有的具体工厂和抽象工厂。
以上，就是我对AbstractFactory的理解，希望大家斧正。