(创建模式)工厂模式factory method

1：简单工厂模式的引入与不足
为了提高内聚(Cohesion)和松耦合(Coupling)，我们经常会抽象出一些类的公共接口以形成抽象基类或者接口。这样我们可以通过声明一个指向基类的指针来指向实际的子类实现，达到了多态的目的
这里很容易出现的一个问题n多的子类继承自抽象基类，我们不得不在每次要用到子类的地方就编写诸如new ×××;的代码，这里带来两个问题：
(1)客户程序员必须知道实际子类的名称
(2)程序的扩展性和维护变得越来越困难(需要修改工厂类)
2：工程模式对简单工厂模式的改进
定义一用于个创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类
3：UML
(图)

工厂(creator)角色、具体工厂(concrete creator)角色；

抽象(product)角色、具体产品(concrete product)角色。
4：特点
工厂模式实现时，客户端决定实例化哪一个工厂来实现产品类，选择判断的逻辑还是存在的!也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行!
需要扩展时，本来是改工厂类，而现在是修改客户端!
5：缺点
可以看出工厂方法的加入，使得对象的数量成倍增长，当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。
因为如果不能避免这种情况，可以考虑使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现