说到就近原则，想必大家都不陌生，在生活中我们经常使用。
午饭叫外货，可以根据店家距离选择，距离近的送货比较准时，甚至可以提前送到。
下班购物，更有可能选择回家路上的商场。这个就近原则，是物理距离上的近。
网页中的CSS样式文件，如果有多个样式约束，比如字体大小的控制。一个全局的样式文件，一个局部的样式文件，还有一个写在页面元素上的字体大小。那么哪个样式会起作用呢？当然是写在页面元素上的字体大小在起作用，还有一个前提要写对。
前几天新增的业务逻辑，又让我想到了就近原则。
新增的业务逻辑是这样的，新增两个开关，一个在用户设置里，一个在用户的好友设置里。开关打开的时候，某个页面元素展示。开关关闭的时候，那个页面元素不展示。
我把数据库的表结构调整了一下，便把任务分配给开发A。A编码了一半，跑过来问：“用户设置里新加的开关是控制全局的呢？还是控制...”
“用户设置里的开关是控制全局的”，突然觉得不对，如果控制全局的，那影响太大了，于是改口道：“不对，用户设置里的开关是针对陌生人搜索用的。用户的好友里的开关只针对这一个好友的。”
“好的”，A回去继续编码。A编码完，把这两个字段的控制范围作为备注加到了任务日志里。
没多久，便看见产品助理B一路小跑到A的座位旁，拉着A讨论着什么，声音太小，不知道说了啥，又引出了什么不确定因素吗？
这时，产品经理C从他们的座位旁走过。
B拦住C便问：“昨天讨论的用户设置里的开关是不是全局的？用户设置里的开关一有变更，用户好友里的设置也被改变了？”
“那个呀”，C停顿了一下，“用户设置里的开关，只对新加的好友起作用...”
“我认为应该是全局的，也对好友起作用！”，B很坚定地说。
“一关全关，一开全开？”，C一脸疑惑的样子。
“不是的，用户设置里的开关虽然改变，但用户好友的那个开关状态会保持。也就是说，用户设置里的开关开了，并且用户好友里的设置也开了，这个页面元素才展示。用户设置开关关了，好友里的开关保持不变，但页面元素不展示！”，B一口气说完她心里的逻辑。
“那样也行吧”，C开始妥协。B开始和A解释想要的效果。
“用户设置对好友是不可见的，对好友的设置是保存在用户的好友表的。而用户的好友信息是缓存在客户端的。要么没有关系，要么一改全改。用户的好友表里的开关状态想保持，不好保存呀？”，B还没有开始说，我便插了嘴。
“那就用老板说的策略吧”，B听了我的话后，立马改变策略。
“以前不是有这样的设置吗？”，C皱着眉头反问道。
“这种情况的设置还是第一个”，我和B异口同声。
“我开会不是说了这个规则吗？”，C还是满脸疑惑。
“你也就和我一个人说了吧？”，B抛给产品经理一个白眼。
“我们三个人有三个理解，加上你一共四个理解...”，我轻描淡写，我们的产品经理加老板什么时候才能不拍屁股决定一个业务逻辑呢。
“好吧，以后我要拿个大喇叭喊了”，老板笑着走开。
我们又各自干起各自的活来。、
图片
UML图假设这个开关就叫做标签开关，用来设置自己的标签对于外部是否展示的。这个外部包含三个部分：
- 陌生人搜索到用户的时候，标签是否展示；
- 陌生人添加用户时，标签是否展示；
- 已经加过的好友，标签是否展示。
当然，用户的好友表，也有同样的一个标签开关，这和用户设置里的标签开关是不是冲突了呢？从表面上看是冲突的。用户设置里的标签开关有变更的时候，用户好友表的标签是否也需要变更呢？这也是A的疑惑。先来分析一下3种方案：
- 用户设置表的标签开关，与用户好友表的标签开关，保持同步；
- 用户设置表的标签开关，与用户好友表的标签开关，互不影响；
2.1 用户设置表的标签开关只针对陌生人；
2.2 用户设置表的标签开关只针对陌生人和新加好友；
第1种，用户设置表一有变更，就需要通知所有的好友，改动太大。
第2种情况，用户设置表的标签开关，只在陌生人检索到用户的时候，才根据开关判断是否展示标签，影响比较小。这种情况也是我一开始所想。
第3种情况，在第2种情况的基础上，再增加一种情况，被加好友时，把标签开关也同步过去，只针对这一个好友，影响也比较小。这种情况也是产品经理C想要的效果。
用户设置属于用户的隐私设置，对于好友是不可见的。用户好友里的设置，对好友是可见的。用户好友里的标签开关，一有变更，就通知到对方的好友表里，缓存在本地。而用户设置，则只针对陌生人和相加的好友。这便是功能上的就近原则。
除了功能上的就近原则。我还想起了项目中的配置文件，配置文件也是有优先级和远近距离的。如果有多处重复配置，那么哪个配置最后读取或优先级最高，则使用哪个配置文件，这也是就近原则。有时候我们修改了配置文件，但是没有效果，就是因为我们修改的配置文件不是最近的配置文件。
网友评论