spring切面技术之代码优雅设计-偷梁换柱与以彼之道还施彼身

业务背景：出于资源的节约，考虑有两个系统（A系统、B系统（已经上线了））用的是同一个redis群，这就可能会出现key值的冲突，因此A系统的key需要统一添加A系统前缀标识予以区分。
本文针对多系统共用Redis导致的key冲突问题，提出三种解决方案：全量代码修改、工具类重构和切面技术。重点阐述第三种方案，通过AOP技术对RedisTemplate的public方法进行拦截，在不修改原工具类的情况下，自定义实现类完成key前缀的自动添加。方案采用"偷梁换柱"策略，保留原有功能的同时增加前缀处理逻辑，实现零侵入式改造。最终通过配置化方式实现通用性，既保证系统隔离性，又维护了代码优雅性。该方案体现了Spring技术的灵活运用，在满足业务需求的同时，展现了技术方案设计的艺术。
我们先去看一下redis操作工具实现类，可以明显的发现，那个redis操作工具类不是public修饰的，显然，那几个大佬是不允许别人修改（切入）他们的工具实现类。

那么这个切面方式就不可行了嘛？

当然不是，他们既然写了工具类，就一定是要给别人用的，就一定会有public的入口。且看下图所示：

看这代码，想要直接对他的工具实现类入手是一点机会都没有了。
大佬，他不想让你直接对他的方法有任何改动，就用一个第三方来作为公开的中介。所以我们每次调的时候，都要借用RedisTemplate，这样secRedisTemplate.opsForValue().set…，来操作redis，看起来多此一举，实则有深意。
那我们就从第三方中介RedisTemplate中public修饰的opsForValue()这个方法入手吧。
第一步：切面技术之偷梁换柱。
将大佬的redis操作实现类，换成我们自己的实现类。即我们也写一个实现类，同样也实现ValueOperations这个接口
大佬的：

咱们的：

切面代码：

第二步：以彼之道，还施彼身。
即我们的实现类，加了我们自己的逻辑之后，再调用大佬的实现类的方法。
先看切入方法opsForValue的代码实现：

再看默认使用的代码实现redisTemplatePrefixKey：

这个实现类具有通用属性，并且采用配置化。
如此，咱们不用改其他地方的任何代码，即可完成我们的业务需求。
打完，收工。
体会：sping的技术思想，结合我们的需求灵活运用，既可省时省力，又不失优雅帅气。最重要的是有一份快乐夹杂其中。那种快感就像前端实现了页面的某种效果一样舒畅。当然，快乐不是重点，毕竟，优雅，永不过时。