学习不用那么功利,二师兄带你一起轻松读源码~
番外篇简介
Nacos源码分析系列文章,在开篇已经提到过,写作的目标有两个:第一,能够系统的学习Nacos知识;第二,能够基于Nacos学到涉及到的知识点或面。
为了方便大家学习,相对应的文章标题会有所区别,Nacos原理部分命名按照正常编号进行。而番外篇,也就是技术点的讲解则会在文章编号上添加“EXT-”的前缀。这样,如果大家只想学习Nacos原理知识,则可跳过EXT前缀的文章。
这篇文章我们来看看Nacos Client中对工厂模式的使用。这里分两个步骤来了解,首先看看标准的工厂模式是什么样子的,然后再对比一下Nacos中的实现与标准实现有什么区别。
工厂模式概述
在23种设计模式当中,工厂模式包含两种:工厂方法模式和抽象工厂模式。它们都属于创建型模式,而还有一种简单工厂模式,虽然经常被用到,但可能是过于简单,未被纳入23种设计模式当中。
简单工厂模式
下面先介绍一下,简单工厂模式,并对Nacos中的使用进行对比,并思考为什么会这样设计。
简单工厂模式简介
简单工厂模式,又叫做静态工厂方法(Static Factory Method)模式。简单工厂模式是由一个工厂对象根据不同的参数类型返回不同实例。简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现。
对于简单工厂模式,要解决的问题便是封装实例创建的过程。需要什么类,只需传入一个对应的参数,就可以获得所需的对象,调用者无需知道实例的创建过程。被创建的实例通常都具有共同的父类。
简单工厂模式的结构
UML图展示如下:
简单工厂通常包括三部分:
Factory(工厂):核心部分,负责实现创建所有产品的内部逻辑,工厂类可以被外界直接调用,创建所需对象;
AbstractProduct(抽象产品类):工厂类所创建的所有对象的父类,封装了产品对象的公共方法,所有的具体产品为其子类对象;
ConcreteProduct(具体产品):简单工厂模式的创建目标,实现了抽象产品类,所有被创建的对象都是某个具体类的实例;
其中抽象产品类可以是接口,也可以说抽象类。
简单工厂模式的实现
这里假设Nacos的配置中心服务和命名服务都继承自统一的NacosService,同时都需要提供一个注册方法。
抽象产品类定义如下:
public interface NacosService {
/**
* 注册实例信息
* @param object 实例信息,这里用Object代替
*/
void register(Object object);
}
1
2
3
4
5
6
7
命名服务NamingService的具体实现:
public class NamingService implements NacosService {
@Override
public void register(Object object) {
System.out.println("注册命名服务成功");
}
}
1
2
3
4
5
6
7
配置服务ConfigService的具体实现:
public class ConfigService implements NacosService {
@Override
public void register(Object object) {
System.out.println("配置中心实例注册成功");
}
}
1
2
3
4
5
6
7
提供一个工厂类NacosFactory:
public class NacosFactory {
public static NacosService getService(String name) {
if ("naming".equals(name)) {
return new NamingService();
} else {
return new ConfigService();
}
}
}
1
2
3
4
5
6
7
8
9
10
其中根据传入的参数,生成不同类型的NacosService具体实现。
此时,客户端就可以直接调用该工厂:
public class Client {
public static void main(String[] args) {
NacosService nacosService = NacosFactory.getService("naming");
nacosService.register(new Object());
}
}
1
2
3
4
5
6
7
8
可以看出,此时客户端并不需要关注NacosService的具体实现类是如何被创建的,只需要通过NacosFactory来创建即可。这样,就把比较复杂的创建过程封装在了工厂类中。
简单工厂模式的优缺点
简单工厂模式的优点:
工厂类可包含必要的逻辑判断,可决定不同参数创建不同产品的实例。实现了创建职责的分离;
客户端无需知道所创建具体产品的类名,只需知道参数即可;
通过引入配置文件,可以在不修改任何客户端代码的情况下更换和增加新的具体产品类,在一定程度上提高了系统的灵活性;
简单工厂模式的缺点:
工厂类集成了产品创建逻辑,职责过重;
增加系统中类的个数,增加系统复杂度和理解难度;
违反了设计模式中的开闭原则,新增产品需修改工厂逻辑;
简单工厂模式由于使用了静态工厂方法,造成工厂角色无法形成基于继承的等级结构。
Nacos Client的简单工厂模式
在Nacos的client中,提供了一个NacosFactory的工厂类,该类统一提供了创建ConfigService(配置中心服务)、NamingService(注册中心服务)和NamingMaintainService(注册中心实例操作服务)的实例化方法。
在源码中可以看到是通过如下方式创建NamingService的:
NamingService namingService = NacosFactory.createNamingService(properties);
1
NacosFactory的部分源码:
public class NacosFactory { public static ConfigService createConfigService(Properties properties) throws NacosException { return ConfigFactory.createConfigService(properties); } public static NamingService createNamingService(Properties properties) throws NacosException { return NamingFactory.createNamingService(properties); } // ... 省略其他方法 }
乍一看该类的名字,你可能已经意识到它是工厂模式中的一种。但仔细对比会发现,哪一种好像都不是。
首先,我们来看最终创建出来的NamingService和ConfigService,它们各自独立,并不属于同一个抽象产品类。那这样创建出来也叫简单工厂模式吗?
这里要注意前面定义简单工厂模式时说过“被创建的实例通常都具有共同的父类”,这里的“通常”也就是说大多数情况下是这样的,也允许不实现自同一个接口或抽象类。
其次,我们会发现,NacosFactory中也没有根据方法参数进行不同的对象进行创建,而是直接提供了多个方法来创建不同的对象实例。这又是为什么呢?
这样设计可能出于三个目的:
第一,无论NamingService还是ConfigService,它们本身已经对应的工厂类ConfigFactory和NamingFactory了,如果需要单独创建其实是可以直接调用对应的工厂类的;
第二,NacosFactory存在的目的,本身就是为了达到“聚合”的作用,也就是把所有Nacos相关的服务实例集中对外提供,比如Spring Cloud集成时使用的NacosFactory来创建NamingService,而不是通过NamingFactory来创建。
第三,业务创建比较简单。也就是对于Nacos来说,目前版本中只会提供这三个Service,而不会再多出来其他的,因此开闭原则也就没那么重要了。于是就进行了简化处理。
因此,在使用工厂模式时并不一定非要按标准定义,教条式的进行实现,根据具体的场景可以灵活运用。基本上所有的设计模式都有类似的特点。
Nacos API的简单工厂模式
上面看到的是Nacos Client项目中的简单工厂模式实现,再进一步,我们看看该工厂模式中嵌套的NamingFactory:
public class NamingFactory { public static NamingService createNamingService(Properties properties) throws NacosException { try { Class<?> driverImplClass = Class.forName("com.alibaba.nacos.client.naming.NacosNamingService"); Constructor constructor = driverImplClass.getConstructor(Properties.class); return (NamingService) constructor.newInstance(properties); } catch (Throwable e) { throw new NacosException(NacosException.CLIENT_INVALID_PARAM, e); } } // ... }
在NamingFactory中的实现,才更接近标准的简单工厂模式。因为它提供的createNamingService方法,返回的是抽象产品类NamingService(接口)。而在该方法内部呢,才真正创建了它的实现类,虽然实现类只有一个。
小结
学习本文其实想给大家传递两个观点:第一,阅读源码时,其实我们可以多思考一步,比如看看它用到了什么设计模式或知识点;第二,学习设计模式时一定要活学活用,真实的实践环境变化完全,没必要刻板的按照概念来。活学活用,灵活变动,才达到了学习的最高境界。