那童鞋們，你們覺得這個(gè)需求應(yīng)該放入那個(gè)模塊呢？??
....

你們答對(duì)了！??這個(gè)是屬于文章的一個(gè)子模塊，Tag模塊 --- 專門管理文章的標(biāo)簽，然后和每一篇文章有多對(duì)多關(guān)系的。所以標(biāo)簽?zāi)K歸納入文章模塊中。如果我們的內(nèi)容管理系統(tǒng)做的很大，里面有視頻內(nèi)容，圖文文章等等。我們可以在一開始就把這些統(tǒng)一歸納入“內(nèi)容模塊”，也就是Content模塊中。

前端模塊設(shè)計(jì)

說到了這里前端的童鞋估計(jì)要舉手咯???♂?，前端的我們求關(guān)注呀！“前端是以頁面和交互為單位，不可能和后端一樣按功能邏輯來分解模塊吧？” --- 這個(gè)童鞋說的在理哈。其實(shí)前端和后端的設(shè)計(jì)上是有稍微的不一樣的。

后端會(huì)以業(yè)務(wù)邏輯來分解模塊，但是前端有頁面和數(shù)據(jù)邏輯兩塊的代碼。所以前端相對(duì)比后端就要分開兩種模塊分解思路了。

頁 (排) 面 (版) 的模塊設(shè)計(jì)

• 前端的頁面模塊與產(chǎn)品定義的系統(tǒng)模塊會(huì)更加貼切一些。前端分解的模塊會(huì)跟用戶所看到的操作功能分組。
• 簡單的模塊分解，可以利用產(chǎn)品童鞋給到我們的導(dǎo)航來分解，這樣會(huì)更合理的規(guī)整我們的頁面模塊。
• 如果在頁面功能上再想細(xì)分，那就可以用組件設(shè)計(jì)來分解了。

前端邏輯模塊設(shè)計(jì)

• 幾年前的前端就是個(gè)“切圖仔”，基本不用考慮什么業(yè)務(wù)邏輯，數(shù)據(jù)邏輯，數(shù)據(jù)交互這些技術(shù)領(lǐng)域。但是因?yàn)榍昂蠖朔蛛x現(xiàn)在已經(jīng)變成大多數(shù)公司的研發(fā)策略。慢慢前后端都各自分?jǐn)偭藰I(yè)務(wù)邏輯和數(shù)據(jù)交互等處理。

• 因?yàn)榍岸艘灿写罅康臉I(yè)務(wù)邏輯和交互邏輯，所以在我們封裝和解耦的時(shí)候，也會(huì)遇到需要分解模塊來處理。現(xiàn)在最典型的例子就是在使用Vue的狀態(tài)管理Vuex的時(shí)候，需要用到模塊管理來分解邏輯，使后面維護(hù)和修改更容易。

• 其實(shí)前端也是用后端同一套思維模式來分解業(yè)務(wù)就可以了，以功能為單位來分解你們的模塊就可以了。

解耦 - 「Decoupling」

解耦，就是把復(fù)雜繁瑣的邏輯拆分成更小的邏輯塊。從而讓復(fù)雜的邏輯分解成小的邏輯處理，使得邏輯變得更簡化，更易于調(diào)試和維護(hù)。

在一個(gè)功能眾多、業(yè)務(wù)復(fù)雜和系統(tǒng)模塊繁多的系統(tǒng)中，每一個(gè)模塊里面的代碼也會(huì)開始變得臃腫，越來越難調(diào)試、維護(hù)和管理。其實(shí)模塊化和解耦是一致的。模塊化也是為了解耦你的程序。這里我們重點(diǎn)講的是模塊之間和邏輯之間的解耦（Decouping）。

我分享一個(gè)經(jīng)歷讓大家深刻認(rèn)知到解耦的重要性。我遇到過最夸張的有一段邏輯處理寫了上5000行代碼的童鞋，然而更可怕的是，在相同功能的地方那5000行代碼被復(fù)制粘貼過來了。??我滴乖乖，這位童鞋在研發(fā)小組中有個(gè)花名叫“復(fù)制兄”。不過得到大家的幫忙和提點(diǎn)下，后面他也成為了這個(gè)小組中的一名優(yōu)秀的程序員。

---

如果我們不懂得解耦代碼，編寫的代碼會(huì)給我們后面帶來很重的“技術(shù)債”。假設(shè)一下，你的5000行處理邏輯，在上數(shù)十個(gè)地方使用了。我們要改一下這段邏輯就難過登天了。就算是這段邏輯沒有復(fù)用性，但當(dāng)你需要回頭去修改這段邏輯也是會(huì)讓你頭皮發(fā)麻，無從入手。修改一點(diǎn)這個(gè)邏輯都可能會(huì)導(dǎo)致出現(xiàn)10個(gè)bug的后果。

我們深刻知道解耦的重要性，那么我們應(yīng)該怎么去高效解耦代碼呢？

在《程序員修煉之道》中的 Design by Contract 里提到我們編寫“害羞”的代碼是很有益處的。“害羞”有兩個(gè)含義：“不要把自己暴露給別人”和“不要與過多的人相互影響”。 這個(gè)是什么意思？我們用書中的例子來理解一下。

在一個(gè)龐大的間諜組織中，特工們會(huì)分到各個(gè)小組，每個(gè)小組內(nèi)部的特工基本都互相認(rèn)識(shí)，但是各個(gè)小組之間的特工就都互不相識(shí)。假設(shè)某個(gè)特工被俘虜了，一個(gè)小組可能會(huì)被摧毀，但是其他小組的特工是不會(huì)被暴露被影響的。因?yàn)楦鱾€(gè)小組之間的關(guān)系都是絕對(duì)隔離的。但是在任務(wù)中，各個(gè)小組之間都是會(huì)有合作和互相幫助，但是都互不相識(shí)。所以這么龐大的間諜組織才能長期安全存活下來。

這個(gè)種隔離模式用在編程中是非常好的。把我們的代碼解耦到相對(duì)獨(dú)立的模塊和方法中，讓它們之間的關(guān)聯(lián)性和影響性降到最低。如果一個(gè)模塊或者邏輯方法出了問題，我們可以獨(dú)立重構(gòu)或者修復(fù)，而不會(huì)給其他模塊帶來巨大的影響。只要最終的結(jié)果是一致的，就可以完美優(yōu)化升級(jí)或者修復(fù)了。

在程序中，我們需要一個(gè)Service (服務(wù))給我們處理一個(gè)Object（對(duì)象），或者請(qǐng)求一個(gè)服務(wù)獲得一個(gè)Object，我們希望這個(gè)服務(wù)給到我們需要的結(jié)果，但是不需要我們?nèi)ゲ傩乃窃趺刺幚砼c獲得這個(gè)Object的。這個(gè)服務(wù)或者方法是獨(dú)立運(yùn)行的，里面的邏輯和代碼是與我們寫的代碼絕對(duì)隔離的。我們只需要在獲得結(jié)果的時(shí)候驗(yàn)證這個(gè)結(jié)果的可用性就可以了，如果結(jié)果與我們需要的不一致，那我們就可以拋出錯(cuò)誤。只要這個(gè)服務(wù)做對(duì)應(yīng)的修正，就可以繼續(xù)運(yùn)行了。

理論我們解說的差不多了，現(xiàn)在我們來個(gè)實(shí)戰(zhàn)例子吧：

案例：
假設(shè)現(xiàn)在我們需要寫一個(gè)獲取天氣預(yù)報(bào)數(shù)據(jù)的類，獲取天氣預(yù)報(bào)數(shù)據(jù)首先你需要提供Geolocation 定位信息參數(shù)。Geolocation對(duì)象中含有一個(gè)地址對(duì)象。里面有經(jīng)緯度，省市區(qū)等數(shù)據(jù)。我們需要獲取到地址中的經(jīng)緯度才能得到精準(zhǔn)定點(diǎn)的天氣預(yù)告信息。我們的代碼會(huì)這么寫：

/**
* 獲取天氣方法
*/
public function getWeather(Geolocation $geolocation) {
    // 假設(shè)我們已經(jīng)封裝了一個(gè)獲取定位的天氣的方法叫g(shù)etWeatherByGeo()
    return $this->getWeatherByGeo($geolocation->getLocation()->getLat());
}

• 我們通過getLocation方法獲取到定位對(duì)象里面的地址對(duì)象
• 然后通過getLat()方法獲取到定位地址的經(jīng)緯度信息

以上例子中，因?yàn)槲覀冃枰?code>geolocation對(duì)象中取到經(jīng)緯度，所以我們需要先經(jīng)過獲取地址對(duì)象，然后再通過這個(gè)對(duì)象獲取到經(jīng)緯度。其實(shí)這里面有不需要的關(guān)聯(lián)關(guān)系。無論是寫服務(wù)，還是寫對(duì)象方法，我們都不要讓使用這個(gè)服務(wù)/對(duì)象的開發(fā)者去過度的理解和使用你關(guān)聯(lián)性很強(qiáng)的內(nèi)部方法。這樣會(huì)導(dǎo)致如果我們那天改變了這個(gè)關(guān)聯(lián)性，多處都需要修改代碼。

如果那天劉某改了Geolocation對(duì)象，里面不再含有Location對(duì)象，而且也沒有了getLocation()方法，經(jīng)緯度可以直接在Geolocation對(duì)象中直接取得。這個(gè)時(shí)候所有之前運(yùn)用這個(gè)對(duì)象的其他人都需要修改代碼了。很多時(shí)候開發(fā)者很難修改代碼，或者一改動(dòng)就會(huì)傷筋動(dòng)骨的，其實(shí)就是因?yàn)檫@種過多過度的關(guān)聯(lián)性關(guān)系導(dǎo)致而為的。

所以作為Geolocation對(duì)象的封裝者，我們應(yīng)該直接給到一個(gè)方法getLat()，讓調(diào)用這個(gè)對(duì)象的開發(fā)者直接能拿到所需要的信息：

/**
* 獲取天氣方法
*/
public function getWeather(Geolocation $geolocation) {
    // 假設(shè)我們已經(jīng)封裝了一個(gè)獲取定位的天氣的方法叫g(shù)etWeatherByGeo()
    return $this->getWeatherByGeo($geolocation->getLat());
}

這樣就剪斷了剛剛對(duì)象中的強(qiáng)關(guān)聯(lián)關(guān)系的缺陷。

服務(wù)化 --- 「Service」

服務(wù)定義：

角色：服務(wù)是系統(tǒng)架構(gòu)里面的業(yè)務(wù)處理層。
作用：主要是為了高度解耦和封裝不同場(chǎng)景的業(yè)務(wù)和功能到對(duì)應(yīng)的服務(wù)，然而達(dá)到高度中心化的業(yè)務(wù)代碼。

理解服務(wù)

• 假設(shè)人是一個(gè)控制器，現(xiàn)在拿到了一個(gè)衣服對(duì)象的參數(shù)，然后人擁有一個(gè)洗衣服的方法
• 現(xiàn)在人需要洗衣服，但是手洗效率太低了，所以我們寫了一個(gè)多功能的洗衣機(jī)服務(wù)給到人去使用
• 洗衣機(jī)這個(gè)服務(wù)里面有很多不同洗衣服的方法，但是其實(shí)具體洗衣機(jī)里面的每一個(gè)清洗方法人是不知道怎么實(shí)現(xiàn)的，人都是直接按照提供的功能直接使用。
• 所以服務(wù)里面的所有方法都是解耦在服務(wù)里面，服務(wù)要提供的方法是可以方便人使用的。

這樣說是不是很好理解了？所以最簡單的理解就是：

服務(wù)是用來封裝業(yè)務(wù)邏輯代碼，是一個(gè)獨(dú)立的邏輯層，高度封裝解耦后提供給控制器或者其他需要用到這個(gè)服務(wù)的地方使用的。

編寫思路

? 錯(cuò)誤例子

把所有洗衣機(jī)的方法提供給人使用，那就等同于讓人來決定所有洗衣機(jī)的參數(shù)和清洗步驟。當(dāng)人放衣服到洗衣機(jī)后，要選擇先加水，加多少水，然后清洗開始，清洗多久，再甩干等等。

光想想，洗個(gè)衣服還那么多的選項(xiàng)，還要想怎么樣的洗衣順序才是正確的！ 我太難了！洗個(gè)雞腿哦！(?｀□ ′)?⌒┻━┻

?? 正確例子

洗衣機(jī)服務(wù)實(shí)現(xiàn)了很多不同的常用洗衣服的模式, 比如快速清洗，毛衣清洗，地毯清洗，風(fēng)干，甩干等等。都是一些常用的功能。
每個(gè)功能方法里面其實(shí)調(diào)用了很多洗衣機(jī)封裝好的流程和方法。所以當(dāng)人使用洗衣機(jī)時(shí)，根本就不需要知道這些功能是怎么實(shí)現(xiàn)的，只要知道自己要干嘛，洗衣機(jī)剛好也有這個(gè)模式，直接用就完事兒了。

(???)??哇！ 介么人性化的么！這種洗衣機(jī)給我來一打謝謝！

我寫過一篇詳細(xì)關(guān)于編寫服務(wù)的文章《你真的懂怎么寫服務(wù)層嗎？》，有興趣的童鞋可以前往查看哦。這里我就不詳細(xì)解說了。

總結(jié)

這篇文章已經(jīng)到達(dá)尾聲了，到了這里我們已經(jīng)深刻知道何為易于改編原則，更懂得如何編寫易于改編的代碼。其實(shí)在開發(fā)的過程中，我們還是需要先思考，后設(shè)計(jì)，再編寫。根據(jù)所拿到的的功能需求，做好程序的架構(gòu)設(shè)計(jì)，從而寫出易于改編的程序。只有這樣我們編寫的代碼才能越來越好，走上技術(shù)巔峰！