Java 17 中的模式匹配与和类型
Java 17 中的模式匹配与和类型
从 Spring Security 获取用户谈起
使用 Spring Security做用户校验和权限控制时，常常使用和线程绑定的容器来获取当前登录用户。
// 使用前设置用户，重点的在下一条
SecurityContext context = SecurityContextHolder.createEmptyContext();
context.setAuthentication(anAuthentication);
SecurityContextHolder.setContext(context);
// 在使用时，
public Resonse<Boolean> process(SomeRequest request) {
// code
Object principal = SecurityContextHolder
.getContext()
.getAuthentication()
.getPrincipal();
// code
}
我们来梳理一下，容器可以存放验证过的Authentication，Authentication存放isAuthenticated表示是否验证通过，验证后的用户叫做Principal。security的定义如下：
The identity of the principal being authenticated. In the case of an authentication request with username and password, this would be the username. Callers are expected to populate the principal for an authentication request.
The AuthenticationManager implementation will often return an Authentication containing richer information as the principal for use by the application. Many of the authentication providers will create a UserDetails object as the principal.
这里最值得关注的点实际上是Principal的类型是Object，从语法上来说，可以是任意类型，这就是本文想要讨论的点：对于一个确定的系统，我们获取的Principal实际上只可能是几种类型中的一种，比如我们将用户分为注册用户，管理员，游客三种。在如上的process方法中，我们需要对principal的实际类型进行动态获取（运行时确定），然后执行相关的代码逻辑。
当然，对于用户的划分根据业务各有不同，一些简单的业务直接实现了Security提供的UserDetails接口，其中包含了一些权限的控制策略（账号是否过期、锁定等）。
在MVC模型的 service 层中，如果需要使用用户，最好是显式表示在方法签名中，这样的方法更易测试，方便排除副作用。但是我们的用户虽然限制在（注册用户 | 管理员 | 游客）三种类型下，我们只能使用 Object principal来进行匹配。我们需要在方法的前面进行参数校验，对于不同的方法，如果使用到了principal, 都需要进行这样的参数校验。这样做的缺点是没有了编译器的帮助，传入错误的类型，在运行时才发现。
// 举例：UsernamePasswordAuthenticationToken extends AbstractAuthenticationToken::getName 只能做运行时检查
public String getName() {
if (this.getPrincipal() instanceof UserDetails) {
return ((UserDetails) this.getPrincipal()).getUsername();
}
if (this.getPrincipal() instanceof AuthenticatedPrincipal) {
return ((AuthenticatedPrincipal) this.getPrincipal()).getName();
}
if (this.getPrincipal() instanceof Principal) {
return ((Principal) this.getPrincipal()).getName();
}
return (this.getPrincipal() == null) ? "" : this.getPrincipal().toString();
}
// 根据不同的用户，获取不同的信息
public Response<String> getInfo(Object principal) {
if (principal instanceof Admin admin) return adminGetInfo(admin);
else if (principal instanceof NormalUser normalUser) return normalGetInfo(normalUser);
else if (principal instanceof Guest guest) return guestGetInfo(guest);
else throw MyException("invalid param " + principal);
}
Java 17 借鉴了现代编程语言中的模式匹配思想，可以轻松地解决这个问题。
模式匹配
如果用户限制在固定的数目下，我们可以定义一个类型，其属于（注册用户 | 管理员 | 游客）中的一个，这种类型 Type 称为和类型 sum type，因为其只有三种情况，满足加法法则；如果注册用户将来分成了普通用户和星级用户，则变为 4 种情况。
与sum type对应的 product type，假设 UserInfo 类中拥有 age 和 height 两个字段，则 UserInfo 的实例有 n(age) * n(height) 种情况。
sum type 和 product type 两种类型，称为代数数据类型ADT，ADT在函数式编程中常见。（https://en.wikipedia.org/wiki/Algebraic_data_type）
在一些函数式语言中，没有类和继承，数据 = ADT，对象的行为 = function, 继承 = part of pattern matching。
Java 中借用接口解决和类型的问题：
public Response<String> getInfo(User principal) {
return switch (principal) {
case Admin admin -> adminGetInfo();
case NormalUser user && isSpecialDay() -> getInfoWithEasterEgg(user);
case NormalUser user -> getInfo();
case Guset guest -> guestGetInfo();
}
}
// user 使用sealed class(指定子类), switch 可以不用default.
模式匹配可以实现继承中的动态分派，并且可读性更好。
远古时期的 switch 语句，表达能力有限，只能使用在 int, Enum等类型上，即使如此，使用Enum也可以实现动态分派，如果使用的是 Java 8，可以使用Enum实现方法动态分派，可以参考 On Java 8。
什么时候使用？
面对复杂的 if-else 时
- 可以提取出分派方法的类，使用继承实现和类型 + sealed class，使用模式匹配 + 卫模式guarded pattern(predicate)。
- 不使用sealed class, 使用default 指定默认方法或者抛异常。
- 直接使用继承实现动态分派，这样的话可以直接调用 user.getInfo()。但是这样没法使用卫模式。
- 可以使用状态模式，如上面对用户权限的控制，抽取AuthType接口，根据行为不同，包含AdminAuth, NormalAuth, GuestAuth三种权限，User持有AuthType，权限相关方法委派给AuthType实现，调用authType.getInfo().
- 无法使用Java17 模式匹配，可以使用Enum这样的折中方法，好处是使用了编译器帮助检查Enum的完备性，可以没有default。
- 模式匹配可以完美替换 visitor pattern。比如：保存图片为jpg, cad有多种类型，使用visitor pattern 需要定义saver接口，问题是这个接口需要知道所有的cad类型，新增一个cad类型会很复杂。使用模式匹配改造后，cad.save(new JpgSaver())简化为saveJpg(cad)。原来的Cad.save(Visitor save) 方法实际上通过继承实现了两次分派，一次在Cad，另一次在Visitor。改造之后在saveJpg方法中只发生一次。
