問(wèn)題描述

寫了個(gè)后臺(tái)管理頁(yè)， 用了簡(jiǎn)單的單例模式。類似于

var xxx = { method1: function(){}, method2: function(){}, ...}

想問(wèn)下有經(jīng)驗(yàn)的人， 寫類型于這樣的項(xiàng)目。要怎么組織代碼結(jié)構(gòu)，才能更方便的拓展和維護(hù)。

問(wèn)題解答

后臺(tái)管理，肯定涉及大量的增刪改查，可以手寫一個(gè)MVVM

一般設(shè)計(jì)模式都是針對(duì)程序的可維護(hù)性進(jìn)行使用的，具體來(lái)講就是爭(zhēng)對(duì)一些容易發(fā)生變化的部分做預(yù)防性處理，以至于到后期的維護(hù)中不應(yīng)該修改太多原代碼，特別是已經(jīng)整合好邏輯的代碼。有了上面的認(rèn)識(shí)，這時(shí)我們就可以想了，你的這個(gè)項(xiàng)目要用到大量的增刪改查，刪可能簡(jiǎn)單點(diǎn)，不大可能會(huì)用到什么特別的設(shè)計(jì)模式。我們就先從增開始：

1.添加商品： 無(wú)外乎各種不同參數(shù)的添加和提示，我們至少可以確定未來(lái)一定會(huì)有變化的是新增商品時(shí)，商品具有的參數(shù)項(xiàng)目，就比如說(shuō)我們最開始可能就一個(gè)商品名，一個(gè)庫(kù)存，一個(gè)文字介紹，一個(gè)幻燈片等等，但到后面天殺的產(chǎn)品經(jīng)理說(shuō)我們做的項(xiàng)目不夠清真，我界的修真用戶可能有更多需求，需要多加幾個(gè)填選項(xiàng)，如提供一個(gè)欄目用于客戶發(fā)布不同規(guī)格的商品時(shí)顯示的價(jià)格，或者添加一個(gè)欄目方便客戶在不同節(jié)假日時(shí)折扣價(jià)格的不同等等。總而言之，需求只會(huì)越提越多，不想在后面被這種鬼事情煩死，你就需要一個(gè)良好的設(shè)計(jì)模式來(lái)處理相關(guān)問(wèn)題。這里我可以給你提供的一種模式就是中介者模式（可以盡可能避免模塊之間的耦合，新欄目的添加僅僅只需要將封裝好的模塊傳入到中介函數(shù)中即可，不用在乎其內(nèi)部是怎么處理的，你所需要做的只是提供統(tǒng)一的接口），以后無(wú)論添加多少的參數(shù)填選都只需要完成相關(guān)的邏輯模塊就行。

2.還是添加商品：在上面的功能用了一段時(shí)間后，你家產(chǎn)品經(jīng)理可能已經(jīng)修成金丹，正想大展威風(fēng)，剛好好死不死的你又被坑了進(jìn)去，這次的需求可能是 “要根據(jù)不同的產(chǎn)品類型提供相應(yīng)的參數(shù)填選功能”，就比如說(shuō) 你電子產(chǎn)品類可能需要填詳細(xì)參數(shù)，而游戲點(diǎn)券又不用。這時(shí)我們可以用到的也是最常用的就是 “面向?qū)ο蟆?，也叫模板方法模式，?jiǎn)單來(lái)講就是繼承和重寫。 一個(gè)爸爸，一堆兒子，不含糊，該誰(shuí)上就誰(shuí)上。這種模式相對(duì)比較簡(jiǎn)單。問(wèn)題是在于代碼的復(fù)雜度可能會(huì)有點(diǎn)蛋疼。

3.修改商品： 其實(shí)大部分情況跟新增商品差不多，我們可能需要考慮的是某些特殊需求的時(shí)候。就比如說(shuō)用戶現(xiàn)在正在修改商品信息，但是不希望提交后馬上生效，而且日后希望可以隨時(shí)手動(dòng)控制相關(guān)信息的發(fā)布。這時(shí)你在頁(yè)面上提供了一個(gè)額外的按鈕，用于切換信息發(fā)布和信息保存兩種狀態(tài)，用于區(qū)別在兩種不同狀態(tài)下你對(duì)數(shù)據(jù)不同的處理辦法，甚至以后可能還會(huì)有定時(shí)發(fā)布等等。這時(shí)你可能需要用到策略模式或者是狀態(tài)模式，用于處理在不同策略或狀態(tài)下的行為方法。

4.查商品：最簡(jiǎn)單的，添加不同的過(guò)濾器（如地區(qū)，類型，價(jià)格等等），跟第1點(diǎn)一樣?；蛘呤切枰獙?duì)已經(jīng)讀取到結(jié)果的某些數(shù)據(jù)內(nèi)容進(jìn)行一次查找，比如說(shuō)匹配到“我欲修仙”這幾個(gè)關(guān)鍵字的產(chǎn)品進(jìn)行顯示，其他去掉。因?yàn)槟憧赡芤獙?duì)不同欄目的信息進(jìn)行逐個(gè)匹配，這時(shí)你可以用到職責(zé)鏈模式。

總的來(lái)說(shuō)，我列舉了一些比較常見的設(shè)計(jì)模式，但實(shí)際開發(fā)過(guò)程中遇到的問(wèn)題會(huì)更多，就比如說(shuō)： 你現(xiàn)在需要在新增商品的功能上進(jìn)行一次更新，需求上在用戶每次添加新產(chǎn)品之前，要先做一個(gè)檢測(cè)，判斷用戶以前是否有填過(guò)類似的商品模板，有就提示用戶可直接套用，沒(méi)有則不提示。 但你也許似乎大概仿佛覺得自己快要渡劫了，因?yàn)檫@個(gè)模塊以前是你的同事負(fù)責(zé)的，你又不想讀他的源代碼，這時(shí)你可能需要用到裝飾者模式來(lái)更新相關(guān)的代碼。在保證功能正常的情況下盡量不去修改源代碼。。。。。這樣的例子很多很多，關(guān)鍵要對(duì)事來(lái)操作。至于是否要在項(xiàng)目開始前考慮這么多東西，我認(rèn)為沒(méi)必要，因?yàn)槟愀鞠氩蝗?，你想的和你?shí)際上會(huì)碰到的有時(shí)候是有差距的，你只能選擇一些比較明顯的進(jìn)行規(guī)避，就好像我給你寫了這么多，也僅僅只停留在某些比較明顯的部分，而且我到現(xiàn)在還沒(méi)寫過(guò)這一類項(xiàng)目，具體會(huì)碰到什么問(wèn)題我也只能靠猜猜。 所以不要太糾結(jié)模式的問(wèn)題，等什么時(shí)候回過(guò)神，就什么時(shí)候重構(gòu)代碼， 這樣可能比較好一點(diǎn)。