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