一、开闭原则定义
开闭原则定义：Software entities like classes,modules and functions should be open for extension but closed for modifications.（一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。）
在哲学上，矛盾法则即对立统一的法则，是唯物辩证法的最根本法则。开闭原则在设计模式中也具有同样的重要性且和普遍性。开闭原则是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。可以说开闭原则是最基础的设计原则，其它的五个设计原则都是开闭原则的具体形态，也就是说其它的五个设计原则是指导设计的工具和方法，而开闭原则才是其精神领袖。
开闭原则的定义已经非常明确地告诉我们：软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。
二、案例解析
不得不吐槽，现在的书里举的例子太麻烦了，没错，只能使用“麻烦”来形容，一点都不接地气，看的我头大。。。我来举个接地气的例子吧：
作为Java开发，工作中肯定会涉及到登录接口的开发，登录接口样式代码如下所示
@PostMapping("/login")
public WrapperResult<OAuth2AccessToken> login(@Validated @RequestBody PasswordLoginDto passwordLoginDto) {
OAuth2AccessToken login;
try {
login = iLoginService.login(passwordLoginDto);
} catch (Exception e) {
log.error("", e);
return WrapperResult.faild(e.getMessage());
}
return WrapperResult.success(login);
}
没错，这是一个非常简单的登录接口样例，其中iLoginService.login登录方法包含以下几个步骤：
public OAuth2AccessToken login(PasswordLoginDto dto){
//验证图形验证码有效性
verifyImageCapture(dto);
//验证密码
verifyPassword(dto);
//返回登录token信息
return buildOauthToken(dto);
}
怎样，很简单吧？
现在又来了个新需求：登录不仅要支持密码登录，还要支持手机验证码登录了，这该怎么办？很明显，原来的密码登录接口满足不了需求了，但是我发现一个特点，手机验证码登录和原先的密码登录逻辑很像啊，不同之处就是密码登录验证的是密码，手机验证码登录验证的是手机验证码，那我复用同一个接口，传个类型参数表示不同的登录类型，根据不同的类型走不同的判定逻辑不就行了？
修改下login接口，如下所示
public OAuth2AccessToken login(PasswordLoginDto dto){
//验证图形验证码有效性
verifyImageCapture(dto);
if(dto.isPasswordLogin()){
//验证密码
verifyPassword(dto);
}else{
//验证手机验证码
verifyPhoneCapture(dto);
}
//返回登录token信息
return buildOauthToken(dto);
}
Ok，问题解决，上线测试，非常完美~
过了几天，产品又来新需求了，要支持微信小程序登录的接口：这个接口比较特殊，它登录完成之后要拉取用户信息，并同步到本地数据库。考虑一下，再修改以前登录接口让它支持微信小程序登录方式如何？很明显，再把这段业务逻辑写进去会让原先的login接口变的非常复杂，越来越难维护。。那我把它独立出来写个专门的微信小程序登录接口吧，那不就行了？
密码登录和验证码登录放在一个接口里，微信小程序登录单独的一个接口，似乎不大妥。。没错，密码登录和验证码登录一开始就不应该放在一个接口里，这样密码登录、验证码登陆、微信小程序登录都是单独的接口，互不影响，这样其实是最好的，一开始没遵循开闭原则，将密码登录和验证码登录逻辑搅合在一起，后来发现了想改的代价是比较大的。
三、最佳实践
软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化要知道开闭原则只是个原则。要知道，开闭原则也只是个原则，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但是遵循这6大设计原则基本上可以应对大多数变化。
最佳实践就是：让经验丰富的老手设计系统，他们能尽量预知变化，并有针对性的抽象出接口并拥抱变化。
END.
注意：本文归作者所有，未经作者允许，不得转载