几种工厂模式的区别

　　简单工厂模式，工厂方法模式和抽象工厂模式都是属于建立型设计模式，这三种建立型模式都不须要知道具体类。咱们掌握一种思想，就是在建立一个对象时，须要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变更，项目的扩展。用这三种设计模式均可以实现，那究竟这三种设计模式有什么异同呢？下面根据这三者之间的特色，优势，缺点，适用范围进行比较。

特色

　　简单工厂模式：专门定义一个类来负责建立其余类的实例，被建立的实例一般都具备 共同的父类。它又称为静态工厂方法模式。它的实质是由一个工厂类根据传入的参数，动态决定应该建立哪个产品类（这些产品类继承自一个父类或接口）的实例。简单工厂模式的建立目标，全部建立的对象都是充当这个角色的某个具体类的实例。在这个模式中，工厂类是整个模式的关键所在。它包含必要的判断逻辑，可以根据外界给定的信息，决定究竟应该建立哪一个具体类的对象。用户在使用时能够直接根据工厂类去建立所需的实例，而无需了解这些对象是如何建立以及如何组织的。有利于整个软件体系结构的优化。

　　工厂方法模式：工厂方法是粒度很小的设计模式，由于模式的表现只是一个抽象的方法。 提早定义用于建立对象的接口，让子类决定实例化具体的某一个类，即在工厂和产品中间增长接口，工厂再也不负责产品的建立，由接口针对不一样条件返回具体的类实例，由具体类实例去实现。工厂方法模式是简单工厂模式的衍生，解决了许多简单工厂模式的问题。首先彻底实现‘开－闭 原则’，实现了可扩展。其次实现更复杂的层次结构，能够应用于产品结果复杂的场合。工厂方法模式是对简单工厂模式进行了抽象。有一个抽象的Factory类（能够是抽象类和接口），这个类将不在负责具体的产品生产，而是只制定一些规范，具体的生产工做由其子类去完成。在这个模式中，工厂类和产品类每每能够依次对应。即一个抽象工厂对应一个抽象产品，一个具体工厂对应一个具体产品，这个具体的工厂就负责生产对应的产品。

　　抽象工厂模式：抽象工厂模式是全部形态的工厂模式中最为抽象和最具通常性的一 种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式能够向客户端提供一个接口，使客户端在没必要指定产品的具体的状况下，建立多个产品族中的产品对象。它有多个抽象产品类，每一个抽象产品类能够派生出多个具体产品类，一个抽象工厂类，能够派生出多个具体工厂类，每一个具体工厂类能够建立多个具体产品类的实例。每个模式都是针对必定问题的解决方案，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式针对的是多个产品等级结果。

优势

　　简单工厂模式：工厂类含有必要的判断逻辑，能够决定在何时建立哪个产品类的实 例，客户端能够免除直接建立产品对象的责任，而仅仅"消费"产品。简单工厂模式经过这种作法实现了对责任的分割。简单工厂模式可以根据外界给定的信息，决定究竟应该建立哪一个具体类的对象。经过它，外界能够从直接建立具体产品对象的尴尬局面中摆脱出来。外界与具体类隔离开来，偶合性低。明确区分了各自的职责和权力，有利于整个软件体系结构的优化。

　　工厂方法模式：工厂方法模式是为了克服简单工厂模式的缺点（主要是为了知足OCP）而 设计出来的。简单工厂模式的工厂类随着产品类的增长须要增长不少方法（或代码），而工厂方法模式每一个具体工厂类只完成单一任务，代码简洁。工厂方法模式彻底知足OCP，即它有很是良好的扩展性。

　　抽象工厂模式：抽象工厂模式主要在于应对“新系列”的需求变化。分离了具体的类，抽 象工厂模式帮助你控制一个应用建立的对象的类，由于一个工厂封装建立产品对象的责任和过程。它将客户和类的实现分离，客户经过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出如今客户代码中。它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂便可使用不一样的产品配置，这是由于一个抽象工厂建立了一个完整的产品系列，因此整个产品系列会马上改变。它有利于产品的一致性。当一个系列的产品对象被设计成一块儿工做时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。抽象工厂模式有助于这样的团队的分工，下降了模块间的耦合性，提升了团队开发效率。

缺点

　　简单工厂模式：当产品有复杂的多层等级结构时，工厂类只有本身，以不变应万变，就是模式的缺点。由于工厂类集中了全部产品建立逻辑，一旦不能正常工做，整个系统都要受到影响。系统扩展困难，一旦添加新产品就不得不修改工厂逻辑（若是要增长一个产品，则须要修改工厂类，增长if/else分支，或者增长一个case分支），有可能形成工厂逻辑过于复杂,违背了"开放--封闭"原则(OCP).另外，简单工厂模式一般使用静态工厂方法，这使得没法由子类继承，形成工厂角色没法造成基于继承的等级结构。

　　工厂方法模式：不易于维护，假如某个具体产品类须要进行必定的修改，极可能须要修改对应的工厂类。当同时须要修改多个产品类的时候，对工厂类的修改会变得至关麻烦（对号入座已是个问题了）。

　　抽象工厂模式：抽象工厂模式在于难于应付“新对象”的需求变更。难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是由于抽象工厂几乎肯定了能够被建立的产品集合，支持新种类的产品就须要扩展该工厂接口，这将涉及抽象工厂类及其全部子类的改变。

适用范围

　　简单工厂模式：工厂类负责建立的对象比较少，客户只知道传入了工厂类的参数，对 于始何建立对象（逻辑）不关心。

　　工厂方法模式：当一个类不知道它所必须建立对象的类或一个类但愿由子类来指定它所建立的对象时，当类将建立对象的职责委托给多个帮助子类中的某一个，而且你但愿将哪个帮助子类是代理者这一信息局部化的时候，可使用工厂方法。

　　抽象工厂模式：一个系统不该当依赖于产品类实例如何被建立、组合和表达的细节，这对于全部形态的工厂模式都是重要的。这个系统有多于一个的产品族，而系统只消费其中某一产品族。同属于同一个产品族的产品是在一块儿使用的，这一约束必须在系统的设计中体现出来。系统提供一个产品类的库，全部的产品以一样的接口出现，从而使客户端不依赖于实现。

　　其实，不管是简单工厂模式、工厂模式仍是抽象工厂模式，它们本质上都是将不变的部分提取出来，将可变的部分留做接口，以达到最大程度上的复用。究竟用哪一种设计模式更适合，这要根据具体的业务需求来决定。

　　另外，附上一个关于这几种工厂模式的比喻。不管是简单工厂模式、工厂模式仍是抽象工厂模式，它们本质上都是将不变的部分提取出来，将可变的部分留做接口，以达到最大程度上的复用。拿一个生产水杯（cup）的工厂举例：起初，不用工厂模式，我必须在生产水杯以前知道水杯的材料和形状等水杯的全部特征才能生产，这就是咱们的new Cup();这个Cup必须是具体的。厂主发现同一形状的被子，只是材料不一样,如一个是玻璃(glass)的，一个是瓷(china)的,可是确要两条生产线，显然有资源浪费的嫌疑。如今厂主生产杯子时先不让生产线知道我要产的是玻璃的仍是瓷的，而是让它在不知道具体材料的状况下先作它能作的，等到它把模具作好，只须要向其中填充玻璃原料或者瓷原料就能够造出同一形状的具体杯子了。可是很惋惜，C#并不能new一个抽象的Cup，因此就有了简单工厂模式。原来是Cup cup=new Cup;如今是SimpleCupFactory.createCup(String cupName),根据cup的名字生产Cup,而createCup返回的是一个实现了 Cup接口或抽象类的具体Cup。简单抽象工厂模式有一个问题，就是当我如今想生产一个一样形状的铁杯时，工厂里并无定义相应的处理流程，只能更改createCup方法，这就不合理了。我如今只是想生产铁杯，你只要在最后的时候把玻璃原料换成铁的不就好了吗，干吗还要更改整条生产线呢？因而就有了工厂模式。原来生产线在生产模具的时候还要考虑是为玻璃杯生产的模具仍是为铁杯生产的模具，如今它不用管了。CupFactory.createCup()建立Cup.CupFactory是接口或抽象类。实现它的具体子类会建立符合Cup接口的具体Cup。那么如今厂主想要生产水壶(kettle)，用工厂模式就不得再也不造一条水壶生产线，能不能在水杯生产线同时生产水壶呢？这就是抽象工厂模式。