說到就近原則，想必大家都不陌生，在生活中我們經常使用。
午飯叫外貨，可以根據店家距離選擇，距離近的送貨比較準時，甚至可以提前送到。
下班購物，更有可能選擇回家路上的商場。這個就近原則，是物理距離上的近。
網頁中的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想要的效果。
用戶設置屬於用戶的隱私設置，對於好友是不可見的。用戶好友裏的設置，對好友是可見的。用戶好友裏的標籤開關，一有變更，就通知到對方的好友表裏，緩存在本地。而用戶設置，則只針對陌生人和相加的好友。這便是功能上的就近原則。
除了功能上的就近原則。我還想起了項目中的配置文件，配置文件也是有優先級和遠近距離的。如果有多處重複配置，那麼哪個配置最後讀取或優先級最高，則使用哪個配置文件，這也是就近原則。有時候我們修改了配置文件，但是沒有效果，就是因爲我們修改的配置文件不是最近的配置文件。