寫了個(gè)後臺管理頁， 用了簡單的單例模式。類似於
var xxx = {
method1: function(){},
method2: function(){},
...
}想問下有經(jīng)驗(yàn)的人， 寫類型於這樣的項(xiàng)目。要怎麼組織程式碼結(jié)構(gòu)，才能更方便的拓展與維護(hù)。
2
0
0
一般設(shè)計(jì)模式都是針對程式的可維護(hù)性進(jìn)行使用的，具體來講就是爭對一些容易發(fā)生變化的部分做預(yù)防性處理，以至於到後期的維護(hù)中不應(yīng)該修改太多原代碼，特別是已經(jīng)整合好邏輯的程式碼。有了上面的認(rèn)識，這時(shí)我們就可以想了，你的這個(gè)專案要用到大量的增刪改查，刪可能簡單點(diǎn)，不大可能會用到什麼特別的設(shè)計(jì)模式。我們就先從增開始：
1.新增商品： 無外乎各種不同參數(shù)的添加和提示，我們至少可以確定未來一定會有變化的是新增商品時(shí)，商品具有的參數(shù)項(xiàng)目，就比如說我們最開始可能就一個(gè)商品名，一個(gè)庫存，一個(gè)文字介紹，一個(gè)幻燈片等等，但到後面天殺的產(chǎn)品經(jīng)理說我們做的項(xiàng)目不夠清真，我界的修真用戶可能有更多需求，需要多加幾個(gè)填選項(xiàng)，如提供一個(gè)欄位用於客戶發(fā)布不同規(guī)格的商品時(shí)顯示的價(jià)格，或添加一個(gè)欄位方便客戶在不同節(jié)假日時(shí)折扣價(jià)格的不同等等?？偠灾?，需求只會越提越多，不想在後面被這種鬼事情煩死，你就需要一個(gè)好的設(shè)計(jì)模式來處理相關(guān)問題。這裡我可以給你提供的一種模式就是中介者模式（可以盡可能避免模組之間的耦合，新欄目的添加僅需要將封裝好的模組傳入到中介函數(shù)中即可，不用在乎其內(nèi)部是怎麼處理的，你所需要做的只是提供統(tǒng)一的介面），以後無論增加多少的參數(shù)填選都只需要完成相關(guān)的邏輯模組就行。
2.還是添加商品：在上面的功能用了一段時(shí)間後，你家產(chǎn)品經(jīng)理可能已經(jīng)修成金丹，正想大展威風(fēng)，剛好好死不死的你又被坑了進(jìn)去，這次的需求可能是“要根據(jù)不同的產(chǎn)品類型提供相應(yīng)的參數(shù)填選功能”，就比如說你電子產(chǎn)品類可能需要填寫詳細(xì)參數(shù)，而遊戲點(diǎn)券又不用。這時(shí)我們可以用到的也是最常用的就是 “面向?qū)ο蟆?，也叫模板方法模式，簡單來講就是繼承和重寫。 一個(gè)爸爸，一堆兒子，不含糊，該誰上誰上。這種模式相對比較簡單。問題在於程式碼的複雜度可能會有點(diǎn)頭痛。
3.修改商品： 其實(shí)大部分情況跟新增商品差不多，我們可能需要考慮的是某些特殊需求的時(shí)候。就比如說使用者現(xiàn)在正在修改商品訊息，但是不希望提交後馬上生效，而且日後希望可以隨時(shí)手動(dòng)控制相關(guān)資訊的發(fā)布。這時(shí)你在頁面上提供了一個(gè)額外的按鈕，用於切換資訊發(fā)布和資訊保存兩種狀態(tài)，用於區(qū)別在兩種不同狀態(tài)下你對資料不同的處理辦法，甚至以後可能還會有定時(shí)發(fā)布等等。這時(shí)你可能需要用到策略模式或是狀態(tài)模式，用來處理在不同策略或狀態(tài)下的行為方法。
4.查商品：最簡單的，添加不同的過濾器（如地區(qū)，類型，價(jià)格等等），跟第1點(diǎn)一樣?；蚴切枰獙σ呀?jīng)讀取到結(jié)果的某些數(shù)據(jù)內(nèi)容進(jìn)行一次查找，比如說匹配到“我欲修仙”這幾個(gè)關(guān)鍵字的產(chǎn)品進(jìn)行顯示，其他去掉。因?yàn)槟憧赡芤獙Σ煌瑱谀康馁Y訊逐一匹配，這時(shí)你可以用到職責(zé)鏈模式。
總的來說，我列舉了一些比較常見的設(shè)計(jì)模式，但實(shí)際開發(fā)過程中遇到的問題會更多，就比如說： 你現(xiàn)在需要在新增商品的功能上進(jìn)行一次更新，需求上在在使用者每次新增產(chǎn)品前，要先做一個(gè)檢測，判斷使用者以前是否有填過類似的商品模板，有就提示使用者可直接套用，沒有則不提示。 但你也許似乎彷彿覺得自己快要渡劫了，因?yàn)檫@個(gè)模組以前是你的同事負(fù)責(zé)的，你又不想讀他的源代碼，這時(shí)你可能需要用到裝飾者模式來更新相關(guān)的代碼。在保證功能正常的情況下盡量不去修改原始碼。 。 。 。 。這樣的例子很多很多，關(guān)鍵要對事來操作。至於是否要在專案開始前考慮這麼多東西，我認(rèn)為沒必要，因?yàn)槟愀鞠氩蝗?，你想的和你?shí)際上會碰到的有時(shí)是有差距的，你只能選擇一些比較明顯的進(jìn)行規(guī)避，就好像我給你寫了這麼多，也僅僅只停留在某些比較明顯的部分，而且我到現(xiàn)在還沒寫過這一類項(xiàng)目，具體會碰到什麼問題我也只能靠猜猜。 所以不要太糾結(jié)模式的問題，等什麼時(shí)候回過神，就什麼時(shí)候重構(gòu)程式碼， 這樣可能比較好一點(diǎn)。
