个人对工厂模式的理解

问题：当有一群相关的具体类时（假设拥有DuckStore类，Duck类及其子类RedDuck，WhiteDuck，BlackDuck），我们创建对象是这样的：

这样当我们需要增加或删除新的Duck的子类的时候，每次都必须要来修改这里的代码，会造成系统难以维护和更新；
解决方法：这时候我们就需要引入工厂模式；

工厂模式：
作用：代替了new对象；
好处：① new对象的话，一旦代码有变化或者拓展，就必须改变原来的代码，也就是说你的代码并“对修改关闭”；ps：设计原则之一：对扩展开放，对修改关闭；
             ② 解耦，便于更新和维护；


工厂模式分类：
简单工厂模式（不是一个真正的设计模式，更像是一种编程习惯）
做法：创建一个简单工厂SimpleDuckFactory，把创建对象的代码移到SimpleDuckFactory中;

这时候我们的Duck类就需要引入工厂，如下：

简单工厂的优点：
通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的；
明确了各自的职责和权利，有利于整个软件体系结构的优化；

简单工厂的缺点：
1：扩展性差，增加不同的子类还需要修改工厂方法；
2：不同的产品需要不同的额外参数的时候不支持；

附UML：

工厂方法模式：
让子类做决定！
如何做？
所要做的事情就是把工厂方法中的createDuck放回到DuckStore中，不过要把设置为抽象方法，然后为每个地区创建一个DuckStore的子类；
如下：

想要在创建不同子类对象，得先有鸭子类及其子类才行，不同的鸭子种类让子类去实现

测试：

工厂方法模式总结：
① 定义了一个创建对象的接口，但由子类来决定实例化哪一个，工厂方法让类把实例化推迟到子类；
② 工厂方法就是抽象类提供的一个创建对象的方法的接口；

UML：

工厂方法存在的问题：高层组件(DuckStore)依赖于底层组件(Duck)；（高层组件是指由其他底层组件定义其行为的类）；
ps:设计原则之一：要依赖抽象，不要依赖具体类；不管高层或底层组件，都应该依赖于抽象；


抽象工厂模式：
提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类；

比如说我们需要给鸭子增加原料产品，原料分地区又分很多种，所以需要定义一个接口来创建多个原料；

创建不同的类来实现原料方法；

亚洲原料：

 非洲原料：

这时候需要在Duck类中加入原料信息：

子类的构造器中需要引入原料工厂：

这样一来，原料产品就和客户端解耦了，抽象工厂允许客户使用抽象的接口来创建一组相关的产品，而不需要知道实际创建出的产品
是什么。

UML:关系较为复杂

本人小菜鸟一只，这只是个人对工厂模式的一些理解， 如有不足请指正，定虚心受教。