1、需求背景

以gitee为例，登录验证的方式有多种：

• 用户名密码登录
• 短信验证码登录
• 微信登录

先写一个登录接口，适配所有方式，且要符合开闭原则，方便以后再新增其他登录方式。先定义下传参、响应以及接口API路径

//传参Dto
@Data
public class LoginDto {

    private String name;
    private String password;

    private String phone;
    private String validateCode;

    private String wxCode;

    /**
     * account：账户密码登录
     * sms：手机验证码登录
     * we_chat：微信登录
     */
    private String type;
}

//响应Vo
@Data
@AllArgsConstructor
public class LoginResp {
    private boolean success;
}

//接口定义
@RestController
@RequestMapping("/api/")
public class LoginController {

    @Resource
    private UserService userService;

    @PostMapping("/login")
    public LoginResp login(@RequestBody LoginDto loginDto) {
        return userService.login(loginDto);
    }
    
}

//Service层接口抽象
public interface UserService {

    LoginResp login(LoginDto dto);
}

2、常规想法

最先想到的是用户点击不同的登录方式图标，前端传不同的type，后端根据type走不同的验证逻辑，那Service层代码的实现大概长这样：

@Service
public class UserServiceImpl implements UserService {

    @Override
    public LoginResp login(LoginDto dto) {
        if ("account".equals(dto.getType())) {
            System.out.println("用户名密码登录");
            //try执行用户名密码登录的验证逻辑
            return new LoginResp(true);
        } else if ("sms".equals(dto.getType())) {
            System.out.println("短信验证码登录");
            //try执行短信验证码登录的验证逻辑
            return new LoginResp(true);
        } else if ("we_chat".equals(dto.getType())) {
            System.out.println("微信登录");
            //try执行微信登录的验证逻辑
            return new LoginResp(true);
        } else {
            return new LoginResp(false);
        }
    }
}

如此，繁琐的IF-else且不符合开闭原则。考虑使用设计模式来优化。

3、工厂模式 + 配置文件解耦 + 策略模式

每种登录就是实现登录这个目的的一种策略，因此先想到的应该是策略模式，所有具体策略类所需要实现的接口就是抽象策略类的login方法。其次，前端传不同的type，要调用不同的具体策略类对象，如此，再引入工厂模式。

这样写，以后再增加新的登录方式，工厂类还得改，为了解耦，使用配置文件，不同的登录方式的type，对应一个登录方式的具体策略类。

配置文件如：key为登录方式的type，value为具体策略类的Bean的名字。

login:
  types:
    account: accountGranter
    sms: smsGranter
    we_chat: weChatGranter

以后就把这个关系读到一个Map中使用。这里之所以给type和BeanName建立关系，是因为项目是Spring项目，如果不是，那我也可以给type和策略类的全类名建立映射关系存入Map，以后获取策略类对象，可通过反射，一样可以实现。

4、具体实现

上面提到要建立type和对应具体策略类的Bean的映射关系，这里通过实现 ApplicationContextAware 接口，去获取 ApplicationContext 对象，并通过它访问容器中的其他 bean。首先是读取yml配置，这里不要读login.types，这样以后加新的登录方式，又要改这个配置读取类，直接读login，得到一个types名字的数组

@Data
@Configuration
@ConfigurationProperties(prefix = "login")
public class GranterConfig {
    private Map<String, String> types;
}

定义抽象策略类：

/**
 * 抽象策略类
 */
public interface UserLoginGranter {
    LoginResp login(LoginDto dto);
}

定义每种登录方式的具体策略类：

@Component
public class AccountGranter implements UserLoginGranter {

    @Override
    public LoginResp login(LoginDto dto) {
        System.out.println("用户名密码登录");
        //try执行用户名密码登录的验证逻辑
        return new LoginResp(true);
    }
}

@Component
public class SmsGranter implements UserLoginGranter {
    @Override
    public LoginResp login(LoginDto dto) {
        System.out.println("短信验证码登录");
        //try执行短信验证码登录的验证逻辑
        return new LoginResp(true);
    }
}

@Component
public class WeChatGranter implements UserLoginGranter {

    @Override
    public LoginResp login(LoginDto dto) {
        System.out.println("微信登录");
        //try执行微信登录的验证逻辑
        return new LoginResp(true);
    }
}

定义抽象工厂：这里定义一个static map，实现ApplicationContextAware接口（拿到容器上下文对象ApplicationContext去获取Bean），存入type和具体策略类Bean的映射关系：

/**
 * 操作策略的上下文环境类 工具类
 * 将策略整合起来 方便管理
 */
@Component
public class UserLoginFactory implements ApplicationContextAware {

    @Resource
    private GranterConfig granterConfig;

    private static Map<String, UserLoginGranter> granterPool = new ConcurrentHashMap<>();

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        granterConfig.getTypes().forEach((k, v) -> granterPool.put(k, applicationContext.getBean(v, UserLoginGranter.class)));
    }

    /**
     * 获取具体策略类的对象
     * @param type 登录方式
     * @return 具体策略类的对象Bean
     */
    public UserLoginGranter getGranter (String type) {
        return granterPool.get(type);
    }

}

修改之前繁琐的IF-else，Service层的实现类改为：

@Service
public class UserServiceImpl implements UserService {

    @Resource
    private UserLoginFactory factory;

    @Override
    public LoginResp login(LoginDto dto) {
        UserLoginGranter loginGranter = factory.getGranter(dto.getType());
        if (null == loginGranter) {
            return new LoginResp(false);
        }
        return loginGranter.login(dto);
    }
}

测试下效果：

此后，再扩展另外的登录方式，比如QQ登录认证，只需加个具体策略类以及在application.yaml加个配置

login:
  types:
    account: accountGranter
    sms: smsGranter
    we_chat: weChatGranter
    # 扩展
    qq: qqGranter

核心点：

• 提供多种具体策略的对象，让Spring容器管理
• 提供一个工厂，根据参数返回对应的具体策略对象

5、其他场景

类似的，做订单支付也可以用策略模式，具体支付策略有：

• 支付宝
• 微信
• 银联

再比如做解析不同类型的excel，可以针对不同的格式写具体策略类，所有策略类实现抽象策略类的解析接口：

• xls格式的解析具体策略类
• xlsx格式的解析具体策略类

总之，涉及不同的实现方式（策略），搭配冗长的if-else或者switch的场景，都可以使用策略模式 + 工厂模式做个优化。

6、一点思考

第三方供应商需要上架自己的产品到公司的交易平台，但用户使用产品时，最后一步请求的自然是供应商自己的服务器资源和API。关于这个需求的实现思路，大致是在交易平台需要做接口有效性校验、服务实例有效性校验等，以及消费数据记录。

因为不同的第三方供应商系统有不同的认证方式，想实现打通，就要有不同的具体策略类（比如策略类A是通过appid完成认证，策略类B是通过密钥完成认证），因此考虑使用了策略模式。抽象策略类：

public interface ApiRedirectHandler {

    /**
     * @param headerMap 请求头参数Map
     * @param paramMap 对第三方接口的请求参数
     * @return 返回第三方接用调用的结果
     */
    Object redirect(Map<String, String> headerMap, Map<String, Object> paramMap);


}

前面提到，在交易平台要做一些校验和消费记录落库的操作，这些是对接所有三方系统的公共步骤，而后面请求第三方系统接口肯定要做的鉴权认证以及转发或者调用，则属于各个三方系统的定制化行为。因此，不直接写具体策略类，而是垫一个抽象类，实现这些公共步骤，只让最后定制化行为出现在具体策略类：

@Slf4j
public abstract class AbstractRedirectHandler implements ApiRedirectHandler {

    //抽象类中实现接口的方法
    @Override
    public Object redirect(Map<String, String> headerMap, Map<String, Object> paramMap) {

        //todo: 1.请求有效性验证

       //从请求参数paramMap中拿到你要调用APIId，然后查到的三方系统接口的路径、host等信息
       ApiInfo  apiDetailVo = queryApiInfo(paramMap);
       //API的ID用完了，它不是三方系统接口需要的请求参数，移除
       paramMap.remove("apiId"); 

        //todo: 2.服务实例有效性验证
        
        //request中去写不同三方系统的鉴权、转发或调用逻辑
        val responseData = request(headerMap, paramMap, apiDetailVo);

        //todo: 3.记录消费记录
   		
   		//返回第三方接口的响应结果
        return responseData;
    }

    /**
     * API转发请求，对接时，针对不同的三方系统去定制化实现
     *
     * @param headerMap 头信息
     * @param paramMap  请求参数
     * @Param apiDetailVo 接口信息，如接口路径、服务器host
     * @return 返回第三方接用调用的结果
     */
    protected abstract Object request(Map<String, String> headerMap, Map<String, Object> paramMap, ApiDetailVo apiDetailVo);



}

到此，不同的认证方式对应的不同的具体策略类只需实现这个抽象接口的request方法即可，之前用到的具体策略类：

• AppID认证
• AppSecret认证
• SDK反射（第三方系统自己开发认证方式，提供jar包，公司的交易系统去加载jar包并反射调用第三方系统开发者的request方法）

详见【策略模式 + 反射加载SDK】