3.3 層次與命名規(guī)范
命名規(guī)范
? ? 命名規(guī)范也是單一責(zé)任原則的一種表現(xiàn)形式，命名規(guī)范不只簡(jiǎn)單的約定命名模版，還要有清晰的層次與類的職責(zé)，在良好的層次規(guī)范下再約定統(tǒng)一的命名規(guī)范。
? ? 命名規(guī)范至少需要從模塊命名、包命名、類命名、變量、函數(shù)命名五個(gè)維度去約束。不能只是對(duì)函數(shù)名稱的規(guī)范要求。
混亂的原因
命名規(guī)范的干擾因素：
內(nèi)部業(yè)務(wù)功能的命名
外部功能業(yè)務(wù)的命名
? ?比如說我們?cè)诮o一個(gè)類起名字的時(shí)候，容易收到內(nèi)部或外部的干擾，導(dǎo)致了混亂的命名。例如以商品下單為例。
controller的接口，可能命名為OrderController
service 的接口，可能命名為OrderService
? ?其實(shí)OrderController或是OrderService都不是特別的合適，原因在于Controller的命名可能與界面的交互接口所匹配，所以導(dǎo)致OrderController 可能還有訂單界面的很多其他的功能，例如查詢賬戶的余額接口、展示商家詳情等接口。
? ? 再就是OrderService了，OrderService感覺應(yīng)該是對(duì)Order業(yè)務(wù)的操作，但是單從下單角度來說，他所涉及到的業(yè)務(wù)就不僅僅是Order的業(yè)務(wù)，還會(huì)有商品的庫存業(yè)務(wù)、物流的業(yè)務(wù)、用戶的業(yè)務(wù)、統(tǒng)計(jì)的業(yè)務(wù)，也就是說本身OrderService也是一個(gè)混合的業(yè)務(wù)類。
? ?但是如果你這樣命名了，尤其是OrderService給人感覺應(yīng)該是所有訂單業(yè)務(wù)都有它負(fù)責(zé)，但是由于業(yè)務(wù)的交叉存在，導(dǎo)致OrderService成了一個(gè)復(fù)雜且混亂的對(duì)象，從而失去了它的復(fù)用性和可維護(hù)性。
解決方案
我們通過一個(gè)場(chǎng)景來了解，層次劃分的方案
服務(wù)臺(tái)
? ? 服務(wù)臺(tái)的職責(zé)是引導(dǎo)，其實(shí)就是我們接口Controller層，它是以客戶（請(qǐng)求）為導(dǎo)向的，例如你來辦理注冊(cè)公司的業(yè)務(wù)，那么服務(wù)臺(tái)會(huì)告訴你，你應(yīng)該先辦理公司核名、然后在辦理材料審核、然后在開戶、稅務(wù)登記、打印執(zhí)照等流程。
? ? ?從軟件設(shè)計(jì)來看，這里可以提出兩個(gè)層來
? ? ?一個(gè)是面向UI的Controller層，他的命名可以完成以UI的模塊來命名。
? ? ? 另一個(gè)是面向Controller的服務(wù)層，他的職責(zé)是告訴你窗口的辦理流程與每一個(gè)窗口所需要的材料等要求，簡(jiǎn)單來說它就實(shí)現(xiàn)了窗口調(diào)用層的流程編排。
窗口
? ? ?窗口是完整站在業(yè)務(wù)角度來設(shè)計(jì)的服務(wù)能力，它不關(guān)注用戶個(gè)性化的需求，他只處理本窗口所需要的數(shù)據(jù)與相關(guān)的業(yè)務(wù)。
? ? ?窗口其實(shí)也是有自己的service層，他的service層就是具體的業(yè)務(wù)模型的servce層。與我們?nèi)龑铀f的service層是比一樣的。
業(yè)務(wù)辦理
? ? ?業(yè)務(wù)辦理其實(shí)就是模型交互了，通過模型之間的交互完成業(yè)務(wù)的辦理過程。
檔案存檔
? ? ?檔案存檔就是對(duì)辦理過程以及辦理結(jié)果產(chǎn)生的數(shù)據(jù)進(jìn)行保存的過程。
系統(tǒng)架構(gòu)圖
模塊層次圖
總結(jié)
? ? 命名規(guī)范的前提要有清晰的層次劃分依據(jù)，有了劃分依舊才能有模版、包、類的劃分標(biāo)準(zhǔn)。
然后我們從單一責(zé)任原則來命名變量以及函數(shù)的命名規(guī)范。
小技巧
? ? 為了讓團(tuán)隊(duì)對(duì)模塊和專業(yè)術(shù)語在代碼層面表達(dá)一致，可以設(shè)計(jì)一張統(tǒng)一的術(shù)語統(tǒng)一表。
表的核心字段有
名稱、解釋、變量命名、備注
