在create()方法中返回AliPayIdentityProvider实例，每个工厂都返回对应的实例就可以，客户端在调用时，也要发生相应的改变，不在传入参数来获取实例，而是通过调用对应的工厂来获取实例。比如我们使用支付宝账号登陆
// 调用支付宝工厂 IdentityProviderFactory providerFactory = new AliPayIdentityProviderFactory(); // 获取IdentityProvider IdentityProvider provider = providerFactory.create(); // 一些列第三方认证操作重构之后，我们肯定不会再出现上一次的问题，因为现在每个第三方账号提供方都有自己的工厂，每个产品的构建运行都是独立的。小伙子，恭喜你，你离升职加薪不远了。
在你重构的过程中，你也将简单工厂模式进行了升级，现在它不叫简单工厂模式了，因为它已经不简单了，现在的模式叫作工厂方法模式(Factory Method Pattern)。既然我们都用上了工厂方法模式，那就不妨一起来了解一下工厂方法模式吧。
工厂方法模式的定义工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它也是类创建型模式的一种。工厂方法模式与简单工厂模式的区别在于，在工厂方法模式中，实例的创建不是集中在一个工厂中，而是抽取出来了一个工厂父类，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。就像我们的IdentityProviderFactory类和AliPayIdentityProviderFactory类。
跟简单工厂模式一样，我们对工厂方法模式也进行抽象一下，工厂方法模式有下面四个成员：
抽象产品：定义好产品具有的属性方法，例如IdentityProvider
具体产品：具体的产品实现，例如AliPayIdentityProvider
抽象工厂：定义好工厂的抽象方法，例如IdentityProviderFactory
具体工厂：具体的生产工厂，例如AliPayIdentityProviderFactory
老惯例，一起看看工厂方法模式的UML图，加深印象：
工厂方法模式好处在我们重构第三方账号登录模块的时候，我们已经体验到了，工厂方法模式的好处可不止那么一点，一起来看看工厂方法模式有哪些优点？
工厂方法模式的优点工厂方法模式的扩展性非常强，在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，而只要添加一个具体工厂和具体产品，就可以拥抱变化，就像如果我们现在要接入钉钉账号登陆，我们只需要创建DingDingIdentityProviderFactory和DingDingIdentityProvider就好了
良好的封装性，代码结构清晰。调用者需要一个具体的产品对象时，只需要知道这个产品的类名就可以了，不需要知道具体的创建过程，降低的模块之间的耦合
屏蔽产品类，产品类的实现如何变化，调用者不需要关系，它只关系产品的接口，只要接口保持不变，系统中的上层模块就不需要变化。所以工厂方法模式经常用来解耦，高层模块只需要知道产品的抽象类，实现类不需要关系，这符合迪米特法则，也符合依赖倒置原则。
工厂方法模式虽然有诸多好处，但是它也有不少缺点，因为不可能有完美无缺的设计模式，那我们一起来看看工厂方法模式的缺点。
工厂方法模式的缺点增加了系统复杂度，我们将工厂类拆分出来，无形之中给我们的系统带来了复杂性
增加了开发量，在使用简单工厂模式时，我们只想要添加一个case分支，现在则需要创建类
由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度
总结本文主要简单的介绍了一下简单工厂模式和工厂方法模式这两种设计模式，通过第三方账号登陆这个案例，从简单工厂模式开始，一步一步的到了工厂方法模式。想要更深入的了解工厂模式，需要参考大量的案例，spring等开源框架中应用了大量的设计模式，工厂模式自然少不了，不管学习哪种设计模式，我们都可以去参考这些开源框架，它能够加深你对设计模式的理解。
源代码
文章不足之处，望大家多多指点，共同学习，共同进步
最后