设计模式-策略模式的落地使用

一、 项目背景

此项目经历了从简单暴力的写法转化为策略模式的写法，代码逻辑简洁明了，并且后续新增实现减少冗余，个人觉得代码质量大大提高，更加优雅。此外是个人第一次在项目中使用到设计模式，在此纪念。

1、项目内容：单点登录对接8个系统
2、最初做法：创建一个枚举类，根据传参swithc-case匹配调用serviceImpl对应的业务实现
3、现象：

• 一个service接口里面会有8个方法，一个serviceImpl里面会有8个方法的实现逻辑。
• 此时如果后续项目想要进行代码复用，如果只想用其中一个系统，把整个文件复制过去，会有其余系统的冗余。
• 代码维护不易，如果后续新增系统到了100个，那么一个文件内光代码恐怕就有100*100行了，后续维护者定位到对应的业务代码很麻烦

二、改进

2.1 多态

1、为了避免后续系统增长到100个是我的代码文件长的爆炸，我觉得我应该把每一个系统的实现拆分到不同的实现类文件中
2、在写代码的时候就一直觉得不对劲，我在service定义的每一个接口入参反参都一样，就是名字不一样，换句话说，这8个接口都是干的一件事，但是唯一不同的就是实现的过程。
接口的不同实现？没错，很容易就想到这不就是多态嘛。。。

2.2 整改

1、在service层创建一个接口SsoService，创建ssoToThrid()
2、不同系统定义不同的serviceImpl，实现SsoService，去覆写业务方法
3、在controller层业务实现部分，创建一个ssoService，通过传参swithc-case后使用不同的实现类进行实例化，最后调用ssoService.ssoToThrid即可。这样不管多少个系统，只会调用一个ssoService.ssoToThrid(不会同之前case A:ssoService.ssoToThridA;case B:ssoService.ssoToThridB …)

好处

1、显而易见，每个文件简洁明了，不会发生之前文件长到爆炸的情况
2、便于维护和复用，那个系统出问题了/需要复用，直接找对应的文件，不需要关心其他内容
3、扩展性好，当需要新增对接其他系统时，不需要知道其他系统的实现方式（权限问题），只需要写好对应的实现类即可

三、思考

虽然前后两种方式都使用同样的业务代码，同样的实现方式，只不过在设计的架构上有所更改，但是却能让你的代码减少成为屎山的风险。
有时候代码的好坏不只是看有没有bug，更要在此基础上考虑维护、扩展性、复用等其他问题，这样代码才能变得优雅。