工厂三姐妹对比总结——简单工厂模式&工厂方法模式&抽象工厂模式

简单工厂模式VS工厂方法模式

　　简单工厂模式：

　　工厂方法模式： 

　　由于工厂类和分支耦合，于是我们便根据依赖倒转原则，把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的方法，然后，所有要生产具体类的工厂，就去实现这个接口。

　　工厂方法使一个类的实例化延迟到其子类，核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。（下图相对上图，只是更加突出了接口而已）

　　＊各自优点：

　　简单工厂模式：工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。

　　工厂方法模式：通过看图可以发现，工厂方法模式只是比简单工厂模式多了几个对应运算类的工厂而已，这样一来，我们要是有新的运算功能需要，比如“求M数的N次方”，就不用更改原有的工厂类了，只需要增加此功能的运算类和相应的工厂类就可以了，可以用成对添加来描述。

　　＊各自缺点：

　　简单工厂模式：当产品具有比较复杂的多层结构时，它的工厂类只有一个，这时候再以不变应万变就成为它最大的缺点了。因为工厂类是整个组织的核心，它聚集了所有产品的创建逻辑，一旦工厂不能正常工作，整个系统都会受到影响，可扩展性较差。扩展性差一旦有新的需求，就不得不修改工厂逻辑，这样就会导致工厂逻辑过为复杂，违背了开——闭原则。同时静态工厂方法不利于形成基于继承的等级结构。

　　工厂方法模式：将逻辑判断转移到了客户端，由客户端决定实例化哪一个工厂类来实现运算类，本来是应该修改工厂类的，现在却成了修改客户端。且由于功能的增加，类就会增加，若是需要修改多个类的时候，维护工作量就会增加，所以，工厂方法模式虽然有利于扩展但是不利于维护。

　　PS:还有一个小小的区别：在简单工厂中用static声明方法为静态方法，而工厂方法中却未用到静态方法，原因是：在简单工厂中由于不需要子类进行继承，所以使用静态方法可以避免实例化，可以用类来直接调用方法。而在工厂方法中由于存在继承关系，所以不能使用静态方法．

工厂方法模式VS抽象工厂模式

　　抽象工厂模式：

　　以上两张图上边那张是抽象工厂模式的结构图，下边那张是一个例子，一张图胜过千言万语，我们可以看出抽象工厂模式可以定义一系列即多个产品类和多个对象接口，分别派生出多个子类；而工厂方法模式只需要定义一个接口，然后派生出多个子类。

　　*优点：

　　只需要改变具体工厂即可使用不同的产品配置；

　　它让具体的创建实例过程与客户端分离，客户端是通过他们的抽象接口操作实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

　　*缺点：增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了“开闭原则”。

我的理解

　　下面阐述一下我对工厂三姐妹的理解：

　　从一个专门装水果的样子有点寒酸的箱子说起吧～假设下面的这个箱子是专门用来装水果的，至于怎么装，因工厂模式而异~

　　简单工厂模式：这个箱子里边装满了各种水果，在简单工厂模式中就是大杂烩，想吃哪个就拿哪个（还得翻翻找找）没有了，需要往里边添加。

　　工厂方法模式：总公司只经营水果，下边的子公司分别经营一类水果，比如子公司A经营苹果，子公司B经营香蕉……

　　抽象工厂模式：不得不说他的野心不小，仅仅经营水果觉得赚钱少，于是乎，顺应时代潮流，各种“跨界”，大有“横扫六合”之势。

　　综上所述，这三种模式的演进很像是打包，更像是野心的膨胀~