设计模式——简单工厂模式和工厂模式
简单工厂模式(不属于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+个类实现接口类,最后再定义一个工厂类,通过传入的参数不同,创建不同实例。再通过多态的方法调用不同实例的具体实现方法。这样实现,即使以后需要新增同步数据的总类,也不会改动原来的代码,只需要新建实现类。降低了耦合,便于维护。
工厂模式
工厂模式和简单工厂模式的区别主要有,工厂模式对于每个具体产品对象都对应有一个工厂类,这些工厂类都实现了同一个抽象工厂接口。相对于简单工厂模式,工厂模式解决了随着产品增多工厂逻辑复杂的问题,也更符合开闭原则。但因为引入工厂类,会造成类增多、项目结构更复杂。
抽象工厂模式