摘要：按信息熵的觀點這種模式對熵的降低最大。但是，這將增加處理程序的復雜性，程序并不能輕松的自動處理，或者要將多對多關聯分解成純粹的和有其他數據的兩種模式。模式是普遍存在的，從到。

4月份遺漏了一篇，這篇算是補充。

此文并非對設計模式的總結，而是要談談一般的編碼風格，找設計模式的朋友可以移步了。

什么是模式？我搜到一個簡短的解釋：模式是指從生產經驗和生活經驗中經過抽象和升華提煉出來的核心知識體系。

模式是多個生活、生產行為的歸納總結，也就是解決某一類問題的方法論。從信息的角度來理解，模式是對信息減小信息熵的過程和結果。

比如一個 APP 需要組織一個表單，表單里的部分元素如選項列表由服務器提供，假設是一個行業列表，通?？赡芏x一個列表：

[
    {trade_id: 10, trade_name: "xdfsdf"},
    ...
]

看上去接口提供的這個數據沒什么問題。如果此時表單里還有選項列表，選擇城市，那你可能很自然想到 {city_id: 25, city_name: "wefel"} 。對于客戶端，問題也不大，MVC 模式嘛，我在 Model 里分別指定不就行了。

嗯，你也許猜到我想說什么了，沒錯，我想用一個可更簡單的、可復用的結構來進行描述。如：

[
    {id: 10, name: "xdfsdf"},
    ...
]

甚至：

[
    [10, "xdfsdf"],
    ...
]

這樣對此類控件可以更容易的封裝使用。按信息熵的觀點這種模式對熵的降低最大。

但這種轉換您可能嗤之以鼻：『切，這算什么模式？』

我覺得當開始思考模式時，就是在思考事物與事物間的關聯，這才是一個程序員(Programmer)該做的事情；如果僅僅是為了寫點代碼實現某個功能，那該叫編碼員(Coder)。

對照模式的解釋，算法也是模式；我念書少，一直對算法掌握的比較弱，所以此文也就不班門弄斧了。在這里對僅對常規的 MIS（管理信息系統）的接口數據結構提出一些看法，主要針對數據的 CRUD（增刪改查）。

假設要為一家餐館做一個小型 App，需求是構建菜譜，有單品，有套餐。單品的屬性有：名稱、單價、簡介、照片（多個，文件、說明），套餐有：名稱、折扣價、簡介、餐品（多個）。繪制 ERM 如下：

單品和套餐通?？梢猿霈F在一個搜索列表里，屬性基本一致，故放在同一張表里（模式出現了）。照片能夠復用，比如單品可以引用，某個套餐也可以用，甚至系統其他的地方也可以用（這就是模式），那就獨立出來好了（沒有 Product_id 而是用 Product_has_Picture 的多對多關系）。

下面我們開始設計 REST 接口：

GET    /xxx/products
Response Content: [
    {
        id: "商品 ID",
        name: "名稱",
        note: "簡介",
        price: "價格, 格式: RMB ###.##",
        is_package: "是否是套餐",
        main_picture: "主要展示照片 URL"
    }
]

GET    /xxx/products/ID
Response Content: {
    id: "Product ID",
    name: "名稱",
    note: "簡介",
    price: "價格, 格式: RMB ###.##",
    is_package: "是否是套餐",
    pictures: [
        {
            id: "照片 ID",
            name: "名稱",
            note: "簡介"
        }
    ],
    products: [
        {
            id: "商品 ID",
            name: "名稱",
            note: "簡介",
            price: "價格, 格式: RMB ###.##",
            main_picture: "主要展示照片 URL",
            is_free: "是否免費附送"
        }
    ]
}

POST   /www/products
PUT    /www/products/ID
Request Content: {
    name: "名稱",
    note: "簡介",
    price: "價格, 格式: RMB ###.##",
    is_package: "是否是套餐",
    pictures: [
        {
            Picture_id: "照片 ID",
            is_main: "0或1"
        }
    ]
}

DELETE /www/products/ID

看上去沒什么特殊的呀！細心的話也許發現了，GET 拿到的 pictures 列表與 POST、PUT 發送的 pictures 列表結構不一致，這是根據我的框架能識別的模式所做的精簡，事實上 pictures 的完整結構為：

Product_has_Picture: [
    {
        Product_id: "商品ID",
        Picture_id: "照片ID",
        is_main: "是否是主照片",
        Picture: {
            id: "照片ID",
            name: "照片名稱",
            note: "照片說明"
        }
    }
]

在進行商品的創建和修改時，由于照片是從照片列表（接口）選擇的，故 Picture 層是不需要的。如果用類似 Protobuf 的方式描述 Product 的數據結構，應該是：

message Picture {
    required int323 id = 1;
    required string name = 2;
    required string note = 3;
}

message Product {
    required int32 id = 1;
    required string name = 2;
    optional string note = 3;
    required float price = 4;
    optional bool is_package = 5;

    message Pictures {
        required Picture picture = 1;
        optional bool is_main = 2 [default = 0];
    }
    repeated Pictures pictures = 6;

    message Products {
        required Product product = 1;
        optional bool is_main = 2 [default = 0];
    }
    repeated Products products = 7;
}

可以看出 Pictures 內是單個的 Picture 對象，重復的是 Pictures 對象；如果僅僅按數據結構越簡單越好的模式來評判，假設 Pictures 列表不需要 is_main 屬性，按第一個圖即為默認圖的方式好了，也就是 Product 內直接定義 repeated Picture pictures。那么，PUT Product 時 pictures 可定義為一個由 ID 組成的列表甚至分隔符分隔的字符串。但是，這將增加處理程序的復雜性，程序并不能輕松的自動處理，或者要將多對多關聯分解成純粹的和有其他數據的兩種模式。

這里涉及到另一個模式，我們的數據關聯方式到底有多少種，多數的 ORM 框架會給你這樣幾種：BLONGS_TO HAS_ONE HAS_MANY MANY_TO_MANY，但當從 ERM 轉為類圖的時候，你會發現其實只有一種關系即可完整覆蓋這 4 種關系，那就是 BELONGS_TO，在類圖里叫 Dependency （個人覺得對 UML 的 Association Aggregation 等其他名詞沒必要太較勁）。

為了顯式的申明當前關聯查詢的表，確定關聯方向，保留 HAS_ONE、HAS_MANY 便于理解（其實是我嫌麻煩，Django 就做到了只要申明了 ForeignKey 就可以正、反雙向的關聯查詢），由此可得出 A MANY_TO_MANY C 可以分解為 A HAS_MANY B (by A_ID) BELONGS_TO C (by C_ID)。

當理清楚了這個結構模式時，就可以編寫程序『自動』處理請求了，比如你給了 products 數據 {product_id: 31, is_main: 1}，就會去寫入 Product_has_Picture 的關聯數據, 外鍵 package_id 可以自動代入。查詢商品列表時給了 products.product_id 就會提取含有某個（些）商品的套餐。

以此看來，數據本身就成了『查詢語句』和『業務邏輯』。

說完了結構再說說行為。對于常規的 CRUD，我認為從視覺操作上可以分解為兩個組件：列表、表單；列表對應的接口有：獲取列表、更新；表單對應的接口有：獲取信息、保存(增加、修改)。

獲取列表接口可涵蓋：分頁、排序、搜索（篩選）等；
列表的更新有：刪除、更新狀態（批量更新某個字段的值）；

在多年以前 WEB 開發中頁面與頁面（組件）間的聯動是靠顯式的告知回跳地址或用 Referer 來回到來源處，比如連貫的行為：打開列表->添加商品->添加完成->跳回列表。

而獨立的組件模式，組件與組件之間的聯動是采用事件來驅動，A組件完成后廣播自己完成的事件，哪個組件需要處理哪個組件監聽該事件就好了，簡單總結為：誰打開、誰負責。比如現有連貫操作：打開 A 列表->添加 A->進入 A 表單->選擇 B->打開 B 列表->搜索 B->結果里沒有->添加 B->打開 B 表單->保存 B->返回 A 表單->自動選中剛添加的 B->保存 A->刷新 A 列表。

這看上去好像很麻煩，用獨立組件的方式就很好理解了：

A 列表打開 B 選擇列表，此時監聽 B 的選擇完成事件

B 選擇列表打開 B 表單，此時監聽 B 的保存完成事件

當 B 列表監聽到打開的 B 表單保存完成時，觸發 B 選擇完成事件

當 A 列表監聽到打開的 B 列表選擇完成時，將選中數據加入選項并選中

這種方式在 App 和 Web 的 Rich Client 開發中其實很常見。此處表單的選擇是一個封裝了打開、監聽、選中這些行為的控件；每個組件、控件都僅僅關心自己打開的組件即可，并不需要關注完整的行為；其實平時工作中的人何嘗不是如此，問題在于我們總是把問題搞得很復雜，而覺得花時間去思考它們的共性是在浪費時間。

創建一個訂單，挑選幾個商品。

我要的商品不存在，那就建一個好了。純舉例，哪有餐館沒菜顧客自己動手的道理

利用模式，可以把一系列動作、判斷用一個靜態的描述來定義，比如一組表單驗證，一個表關聯關系描述。

而在行為模式上，將關注點從一系列動作縮小到兩者之間關系的描述上。對程序復用和方便人操作識別都有價值。

模式是普遍存在的，從 HTTP 到 SQL。不是我們缺少模式，而是太多的精力和時間耗費在了模式的轉換上，而忽略了模式與模式間轉換的模式的思考。

模式就是要建立起一個足夠『傻』的描述，如同《阿甘正傳》里甘去見珍妮時坐在長凳上對路人說：

  
Mama always said "There"s an awful lot you can tell about a person by their shoes." Where they"re going. Where they"ve been.（媽媽常說看一個人的鞋子你就可以知道他的很多事情。他們要去哪里，去過哪里。）

  
模式 http://www.baike.com/wiki/%E6%A8%A1%E5%BC%8F
信息熵 http://baike.baidu.com/view/401605.htm
《Google Protocol Buffers 入門》 http://shitouer.cn/2013/04/google-protocol-buffers-tutorial/
《UML類圖符號 各種關系說明以及舉例》 http://www.cnblogs.com/duanxz/archive/2012/06/13/2547801.html
HongsCORE for Javascript https://github.com/ihongs/HongsCORE/tree/develop/hongs-web/web/common