【学习笔记第3弹】封装变化——面向配置编程求生声明：小弟是个初学者，理解得不到位的地方，欢迎各位大佬指出，必虚心改进，但

求生声明：小弟是个初学者，理解得不到位的地方，欢迎各位大佬指出，必虚心改进，但也拒绝喷子和引战。

一、案例引入：钉钉消息提醒

需求：当系统发布采购订单后，提醒业务员。

"尊敬的XXX，您的采购订单XXXX（采购订单号）已发布，请进入XX-XX下面处理!"

这个需求里面，哪些是变化的呢？

姓名和采购订单号！

 "尊敬的【users】，您的采购订单【order_number】已发布，请进入XX-XX下面处理!"

过两天用户又想加个消息前缀：

"来自XXX系统的提醒！尊敬的XXX，您的采购订单XXXX（采购订单号）已发布，请进入XX-XX下面处理!"

好，我给你加上！不就是一个if else 的事么？

IF...
ELSE IF ...
ELSE IF...，

可是。过两天用户又想改！每加一种场景，就会多一段 else if ...。

什么是配置？

想象一下QQ的【动态】菜单，下面有很多功能，随着版本的迭代，功能越来越多，但并不是每个人都需要所有的功能，怎么办？

于是动态菜单有了设置，可以将功能打开关闭（猜测只是个显示隐藏控件），这就是配置，将功能的选择权交给用户，而不是开发者预先设定。

如何实现？

大家都做过省市二级联动，原理是一样的。配置其实就是将用户的选择，作为数据条件存储起来，代码运行时，查询用户的选择，来判断下一步怎么走（拼接不同的消息），以此实现不同的场景。

这也就是解耦合思想，将耦合性很强的两部分，通过加一个中间件，进行解耦合。修改对外封闭，扩展对外开发。

代码的变化就是

if （'字符串' == 变量）
 else if ('字符串' == 变量)
 else if ('字符串' == 变量)
 ...

变成

IF （变量 == 变量）

这样我就只用写一个IF，不用增加else if，就可以实现不断增加业务场景。

新增一张配置表，将用户选择的：消息内容，消息类型等等，存储在表里。发消息的时候，去配置表里查询，根据查询出来的结果，拼接消息。

这样，无论用户想增加多少业务场景。直接让他去配置界面配，想要什么样的消息格式，自己去写。达到了扩展对外开发的效果。

在上面这个需求中，不变的是发送消息部分，变化的是拼接消息部分，但拼接消息部分并不全都是变化的，我们要将其中变化的抽取出来，和其中不变的分开，就是封装变化。

原来封装变化是为了日后的可扩展性。

刚入门时只看视频，知其所以，而不知其所以然；后来买书看，理论知识太抽象，生涩难懂，没有实践，看了就忘。最快成长，是理论结合实际。

截图来自：HeadFirst设计模式，在后台回复：学习资料。即可。最好买纸质书籍，经济条件不允许也可以购买二手的，扫描下方二维码，22 - 5 = 17 ，即可到手。

最后说一句：不喜勿喷！

打个广告，欢迎大家关注公众号，会分享一些日常学习笔记和心得。。

欢迎加入qq群一起交流。