工厂模式三姐妹

 

 

简单工厂模式，工厂方法模式和抽象工厂模式都是属于创建型设计模式，这三种创建型模式都不需要知道具体类。我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。这三种模式按照可维护可扩展的特点来看，工厂方法模式是简单工厂模式的进化，而抽象工厂模式，有事工厂方法模式的进化。

 

简单工厂模式：

我们把简单工厂模式比喻成小孩，而小孩有有他自己的属性方法，他封转了爬、坐、走三个方法，要求类是客户端，他只需要调用活动能力类和小孩类就可以完成任务，而不需要 一次调用爬、坐、走，所以，实现了封装。

 

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

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

工厂方法模式：

如果小孩渐渐的长大，他的活动能力更强，学会跑、跳的能力，我们就需要修改代码，首先我们需要在增加跑、跳的类，然后，在小孩类中改变select或者是if条件分支语句，这样，不仅增加了类 ，还需要修改原有的类，这样，违背了开放-封闭原则，这也就是为什么简单工厂模式不能列入gof的23的模式的原因之一。

而此时，我们需要把简单工厂模式中的“小孩”类加以改进，让他符合开放-封闭原则，也就是取出他的select case选择分支语句，让在增加发方法的时候只需要添加类，这样就符合开闭原则。而简单工厂和工厂方法的区别，也就在于此。

 

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

工厂方法模式的优点：工厂方法模式是为了克服简单工厂模式的缺点（主要是为了满足OCP）而设计出来的。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。工厂方法模式完全满足OCP，即它有非常良好的扩展性。

 

抽象工厂模式：我们一直都在写一个小孩的成长过程，但是，如果需要写两个小孩的成长过程，而且我们可以随时切换知道两个小孩的成长过程，那么，我们就应该考虑扩充工厂方法模式，而需求不断演化的过程中，我们就重构了一个非常重要的设计模式：抽象工厂模式

抽象工厂模式的特点：

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

 

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

到此，完成了三个工厂模式的转化，虽然工厂三模式可以说是从简单到复杂，但是这并不意味着抽象工厂模式最好，最差的是简单工厂模式，每个模式存在必有它使用的地方，敏感开发原则告诉我们，不要随便为程序添加大量假设的功能，也就是说，当我们却是不需要知道两个小孩的成长过程时，不需要去假设，然后无端的给自己增加压力，和代码量，所以，我们需要知道模式使用的环境：

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

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

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

 

 

 

结束：其实，只要我们了解工厂模式的核心，就是根据不同的需求封装变化，而本质上并没有多大冲突，就像小孩的成长，如果只需要写一个简单婴儿的时期，程序只用几十行几百行代码就可以，也太不上维护的不方便，那么用简单工厂就可以了，而相对复杂一些的程序，可以用工厂方法模式，而如果有必要了解多个小孩的成长过程，那么抽象工厂就比较适合，也就是说，究竟用哪种设计模式更适合，这要根据具体的业务需求来决定。