我的程式碼會說話 第7章 設計方法的學習

        第七章作者寫得簡潔內容都是精華，設計模式的部分作者用簡潔的語句說明每一種設計模式的作用。Map取代List的部分可與《Code Complete》第18章對照看。

7.1  設計模式

設計模式是針對一些常見的軟體發展問題的可重用解決方案。

GoF提出的23種設計模式，可分為三大類型。

建立型模式：

抽象工廠

建立類別家族的實體

建構者

把物件的建構和其他程式碼分開

工廠方法

建立一個共同的介面的若干個子類別的實體

原型

建立一個被完整初始化的實體，使用在複製時機

單體

使一個類別無論在任何時間訪問，都可以得到唯一的實體。

結構性模式：

適配器

為多個不同的類別之間建立起連接的介面

橋接

物件有多個屬性時，把屬性之間的關連關係從mxn 改為 m+n

組合者

建立一個自相似的樹形結構的節點

裝飾者

動態地為物件增加責任

外觀

透過一個介面來隱藏整個子系統

享元

用一個共用實體來加快存取

代理

用一個物件來代表另外一個物件。

行為型模式：

職責鏈

在一個鏈（chain）間傳遞任務

命令

把命令包裝為物件

直譯者

在一個語言環境中，不同的語言元素代表不同的語義。

迭代器

循環地存取一個串列中的元素

協調者

在物件之間建立一個簡化的溝通類別

備註

儲存物件內部的數值

觀察者

當物件發生變化時通知一組其他的物件

狀態

當物件的狀態變更時，變更處理。

策略

採取不同的演算法進行不同的處理。

樣本方法

把通用的處理放在父類別，具體的實現步驟放在子類別中實作。

訪問者

在不改變物件定義的情況下，定義應用於物件操作。

7.2  相依性注入

程式中相依性可以用程式碼寫死的方式，也可以改成讀取設定檔來完成。用設定檔來定義依賴，不論是在編譯時、執行時，更容易擴展與變更。

外掛程式也是類似的情況，外掛程式到合適的位置註冊，重新開機之後外掛程式會發揮作用，相依性注入使得系統在發佈之後也能夠自由擴展。

相依性注入又稱控制反轉，實現了程式碼的熱插拔。

相依性注入可以透過xml來配置名稱和運算，缺點是程式碼無法獲得IDE支援。如果主程式變更，外掛程式無法即時變更，只有執行的時候才會出現問題。

程式碼若是透過反射加載，會有一點點的效能損失。

7.3  Map 的妙用

1.去掉重複

有時需要在一個List中去除重複的資料。例如發送電子郵件時，去除掉重複的收件人電子郵件地址。

如果只用List來處理，圈複雜度會變高，改用Map可降低圈複雜度。

2.按組統計

當需要把資料按照一定的條件進行分組統計，又不能使用SQL語言，只能透過演算法實現。例如對所有商店本月的銷售業績總額的統計。

用Map取代List可以降低圈複雜度。

3.遊戲中的組合按鍵

遊戲中可讓玩家同時按下多個按鍵，當按鍵數量過多時，程式碼就會變得很長。

作者示範List與Map兩種不同的寫法。

7.4 採用位元遮罩來減少類別的個數

1.位元遮罩

位元遮罩將一個數字每一個位元當做一個開關旗標。n個位元可以表達2的n次方。位元遮罩是減少類別數量的方法。

2.取代多型

採用多型會產生大量類別，採用位元遮罩可在一個類別完成等價操作。

3.替代列舉

有時候常數定義採用列舉，如果需要並列時需要透過||符號或陣列來定義，將會增加程式碼的長度以及判斷的複雜度。

使用位元遮罩的寫法最為簡潔。

7.5 List 處理Z-Order

繪圖軟體需要處理Z-Order這個屬性，直覺想法Z-Order是圖形的一個屬性。

Z-Order是用來表示物件之間順序關係，用List處理會簡單很多。

Z-Order應該作為物件來處理。