设计模式——简单工厂模式和工厂模式

简单工厂模式（不属于23种设计模式）

　　参考博文：https://zhuanlan.zhihu.com/p/390926587。

模式定义：

　　定义一个工厂类，可以根据提供的不同参数，返回不同的实例，并且被创建的实例通常具有共同的父类。

　　uml类如如下：

　　　         　

　　简单来说，product是个一个抽象产品接口，ConcreteProduct类实现了具体的接口方法。而Factory类通过传入不同参数，

生成不同的ConcreteProduct类，而通过多态的方式使用product方法。

　　优点：通过使用工厂类，外部可以免于直接创建具体对象的职责和逻辑，而直接使用对象。（明确了各自的职责和权力）。

　　缺点：工厂类集中了所有产品的创建逻辑，职责过重，一旦异常，整个系统将受影响；并且随着具体产品类数量增加，会引发逻辑复杂和扩展困难。

　　适用场景：工厂类负责创建对的对象比较少；客户端只知道传入工厂类的参数，对如何创建对象不关心

 

　　一些框架涉及的源码分析：

　　　　nacos：

　　　　在Nacos的client中，存在NamingFactory（注册）、ConfigFactory（配置）、NamingMaintainFactory（注册中心）,每个都是一个独立的工厂类，分别生产不同的实例。

然而，另外还有NacosFactory的工厂类，该类统一提供了创建ConfigService（配置中心服务）、NamingService（注册中心服务）和NamingMaintainService（注册中心实例操作服务）

的实例化方法（重载）。

　　　　

 

　　　　初次看到这部分的源码的时候我很疑惑，搞不懂这样设计的意义何在。想要创建任何一个实例对象，直接调用当前实例对象的工厂方法就可以了，给它多加一层简单工厂模式的意义何在呢？

 　　　　在参考了其他博主的文章后，我总结应该是为了聚合。

　　　　首先：是为了把nacos相关的实例集中对外提供，用户想要创建调用实例只需直接关联使用一个类。

　　　　另外：因为nacos的业务只需提供三种不同的实例，也符合简单工厂模式的使用准则。

 

　　个人总结（不一定正确）

　　　　结合个人的项目经验中，如果对于同一个程序入口，接收同样格式/类型的数据，业务场景处理逻辑不一样。并且不同业务场景个数不会太多，并且有可能之后还会有新的操作，可以考虑使用简单工厂模式。

　　　　假设对外提供一个数据同步接口，根据提交的参数不同分别返回3+种类型的数据。可以先定义一个同步接口类，里面存在抽象的业务处理方法。定义3+个类实现接口类，最后再定义一个工厂类，通过传入的参数不同，创建不同实例。再通过多态的方法调用不同实例的具体实现方法。这样实现，即使以后需要新增同步数据的总类，也不会改动原来的代码，只需要新建实现类。降低了耦合，便于维护。

 

 

工厂模式

　　　　

 

　　　　工厂模式和简单工厂模式的区别主要有，工厂模式对于每个具体产品对象都对应有一个工厂类，这些工厂类都实现了同一个抽象工厂接口。相对于简单工厂模式，工厂模式解决了随着产品增多工厂逻辑复杂的问题，也更符合开闭原则。但因为引入工厂类，会造成类增多、项目结构更复杂。

 

抽象工厂模式