航向新世界

01.共通性與可變性分析。(commonality and variability analysis, CVA)

02.抽象概念與實作分離

03.軟體開發過程視角 (p11)

   概念：這種視角「呈現了所研究的領域中的各種慨念... 得出概念模型時應該很少或者不考慮實作他的軟體...」。這個視角要回答的問題是：「軟體要負責什麼？」

   規約：「現在我們要考慮的是軟體，但我們關注的是軟體的介面，而不是實作。」這個視角要回答的問題是：「怎麼使用軟體？」

   實作：這時我麼考慮的是程式碼本身。「這可能是最常用的視角，但在許多方面，採取規約視角經常會更好。」這個視角要回答的問題是：「軟體怎樣履行自己的責任？」

04.分析階段要關注的是問題領域。(p26)

05.過分且無用的繼承，往往是高耦合、低內聚。(p37)

06.依介面設計：(p71)

   a. 用聚合代替繼承。

   b. 找出變化並封裝之。

07.Facade模式意圖：一個一致的高層介面。(p75)

08.Facade提供一組容易理解的功能。(p77)

09.Adapter模式意圖：建立新的介面。為一個功能正確但介面不合的物件建立一個新介面。(p83)

10.物件Adapter模式：一個物件相依包含另一個物件。

   類別Adapter模式：一個類別同時繼承2個類別。(p90)

11.物件：具有責任的實體。(p96)

12.「關注動機，而非實作。」是設計模式中反覆出現的主題。(p98)

13.考慮如何才能夠在不重新設計下進行改變。(p102)

14.將變化封裝、隔離。包含資料變化與行為變化。(p102)

15.當一個類別處理越來越多的不同變化時(例如，透過 switch)，程式碼的內聚性會變得很差，可理解性就越差。(p103)

16.共通性分析：尋找一些共通的要素，它們能夠幫助我們理解系列成員的共同之處在哪裡。(p105)

17.可變性分析：找出如何變化。(p105)

18.共通性分析：尋找的是不可能隨時間而改變的結構。(p106)

19.可變性分析：找出可能變化的結構。(p106)

20.共通性分析：為架構提供長效的要素。(p106)

21.可變性分析：則促進軟體適應實際所需。(p106)

22.抽象類別代表了將所有衍生類別關連起來的核心概念。核心概念定義了衍生類別的共通性。(p107)

23.共通性定義了需要使用的抽象類別。(p107)

24.抽象類別的介面對應於規約層次。(p107)

25.抽象類別（共通性）：需要用什麼介面來處理這個類別的所有責任。(p108)

26.衍生類別（可變性）：對於這個指定的特定實作（這個變化），應該怎樣根據指定的規約來實作它。(p108)

27.規約視角和概念視角之間的關係在於：規約標示了用來處理此概念所有情況（即概念視角所定義的共通性）所需的介面。(p108)

28.規約視角和實作視角之間的關係在於：對於指定的規約，怎樣實作這個特定情況（指的是變化）？(p108)

29.災難往往是由短期未臻最優的決策，長期累積而引起的。(p115)

30.針對介面來設計程式，而不是針對實作來設計程式。(p117)

31.優先使用物件聚合，而不是類別繼承。(p117)

32.考慮設計中什麼是可變的。要考慮什麼能夠在不重新設計的前提下改變。這時主要關注的就是對變化的概念進行封裝。(p117)

33.Strategy模式意圖：定義一系列的算法，把他們一個個的封裝起來，並且使他們可相互替換。可獨立於使用它的客戶而變化。(p127)

34.Bridge模式意圖：將抽象與實作解耦，使它們都可以獨立變化。將一組實作與另一組使用它們的物件分離。(p133)

35.Bridge模式的本質：抽象+實作的組成。(p153)

36.Bridge模式經常與Adapter模式結合。(p154)

37.Abstract Factory模式意圖：為建立一組相關或相依的物件提供一個介面，且無需指定它們的具體類別。(p161)

   生動的說明：根據機器能力選擇設備驅動程式。

38.switch語句可能說明需要抽象的解決方案。(p163)

39.當有多種類型且每個類型有多種類時適合 Abstract Factory 模式。(p175)

40.Alexander：模式定義了問題領域中實體之間的關係。(p186)

41.在軟體設計中使用 Alexander 的方法：(p187)

   a. 找出模式：找出問題領域中存在的模式，用這些模式來思考問題。記住，模式的用途是定義實體之間的關係。

   b. 從背景模式開始：找出為其他模式創造了背景的模式。這些模式應該作為設計的起點。

   c. 然後，從背景轉向內部：觀察其餘模式和任何其他可能已經發現的模式，從中選擇出為其餘模式定義背景的模式。重複這一過程。

   d. 改進設計：改進過程中始終考慮模式所蘊含的背景。

   e. 實作：實作應該融入模式所要求的細節。

42.開閉原則(open-closed principle, OCP)：模組、方法和類別應該對擴展開放，對修改封閉。也就是說，應該將軟體設計成不對其修改就能擴展。(p214)

43.從背景設計原則：透過選擇能夠建立最大的整體概念 -- 系統背景模式。(p214)

44.相依倒置原則(dependency inversion principle, DIP) (p215)

   a. 高層模組不應該相依於低層模組。高層模組與低層模組都應該相依抽象。

   b. 抽象不應該相依於細節。細節應該相依於抽象。

45.Facade的介面經常是隨著使用它的系統部分不斷開發出來而逐步開發出來，開發期間每個新的系統部分都為 Facade 建立了更豐富的背景。

46.封裝變化原則：模式並非只能封裝變化。它們還有助於找到物件之間的關係。(p220)

47.理性懷疑原則：模式都是發現而不是發明出來的。模式實作的具體方式應該由問題領域的本質、約束條件和需求等等決定，而不是根據你在某本書中碰巧看到的某個實作。(p222)

48.隔離變化是設計模式的理念之一。(p225)

49.首先，使用CVA找到問題領域中存在的各種概念(共通性)和具體實作(可變性)。(p225)

50.對於變化，問以下問題：(p227)

   a. 其中一個是另一個的變化嗎？

   b. 它們都是其他東西的變化嗎？

51.有趣的客戶回應：

   a. 客戶會談的非常具體。

   b. 他們經常用「總是」表達「通常」。

   c. 他們經常用「從不」表達「很少」。

   d. 客戶詳細的回答一般是可信的; 但是他們一般性的回答卻不可信。

52.分析矩陣。(p235)

53.在 Abstract Factory 的工廠實作中，使用 Strategy 模式建立各個種類的實作。(p242)

54.分析矩陣的子矩陣。(p244)

55.分析矩陣：左邊第一列為概念。(p236)

56.分析矩陣：「行」為發現的實作。(p240)

57.Decorator模式並不透過一個控制方法控制新增功能，而是建議已需要的正確順序將所需功能串聯起來，進行控制。(p249)

58.Decorator模式意圖：動態給一個物件增加額外的職責。就增加功能來說m，Decorator模式比生成子類別更為靈活。(p250)

59.Decorator模式幫助我們將問題分為兩部分：(p254)

   a. 如何實作提供新功能的物件。

   b. 如何為每種特殊情況組織物件。

60.Observer模式意圖：定義五件間的一種一對多的相依關係，當一個物件的狀態發生改變時，所有相依於它的物件都將得到通知並自動更新。(p266)

61.Template Method模式在一般層次上，步驟是相同的，但是細節不同。(p275)

62.Template Method模式的意圖：定義一個操作中演算法的骨架，而將一些步驟延遲到子類別中。不改變演算法的結構而重新定義它的步驟。(p276)

63.使用 Tempalte Method模式減少冗餘。(p277)

64.Template Method模式並不是耦合多個 Strategy 模式。(p283)

65.Template Method模式適用於幾個互不相同，但概念上相似的過程。(p283)

66.定義新物件時，我們依自己的需要定義它們，使用行為模式作為指導。但是，當我們要將已有的物件加入新的設計中時，使用結構模式作為指導最為合適。

   而使用工廠是隱藏變化的一種自然結果。(p291)

67.何謂工廠？工廠是用來實體化其他物件的方法、物件或其他任何實體。不僅實體化一個物件，而是控制著一組物件。(p290)

68.工廠準則：(p292)

   a. 定義物件和它們的合作方式。

   b. 編寫為相應情況實體化物件並在物件共用時管理已有物件的工廠。

   步驟 1 中的程式碼無需操心哪個物件應該實體化，而步驟 2 中的程式碼則無需操心物件的合作方式。

69.對於物件的建構和管理的通用規則：只負責建構/管理物件或者只負責使用物件。(p293)

70.Double-Checked Locking模式：(p304)

   pubilc static Tax getInstance() {

     if (instance == null) {

        synchronized(this) {

           if (instance == null) instance = new USTax();

        }

     }

     return instance;

   }

71.Object Pool模式意圖：在建立物件比較昂貴，或者對於特定類型能夠建立的物件數目有限制時，管理物件的再利用。(p317)

72.Template Method 模式使用 Factory Method 模式。(p322)

73.Factory Method模式意圖：定義一個用於建立物件的介面，讓子類別決定實體化哪一個類別。Factory Method 使一個類別的實體化延遲到其子類別。(p322)

74.Abstract Factory模式可以用一系列Factory Method模式來實作。(p323)

75.Factory Method 常用於模式框架中。(p323)

76.軟體開發過程視角：概念(conceptual)視角、規約(specification)視角和實作(implementation)視角。在後續討論設計應用程式時可以使用另一組視角：使用(use)視角和建立/管理(creation/management)視角。(p293, p327)

77.概念上相似物件從使用視角來看，可以以同樣的方式處理。(p327)

78.物件導向原則的總結：(p335)

   a. 物件是具有明確定義的責任個體。

   b. 物件對自己負責。

   c. 封裝指的是任何形式的隱藏。(資料、實作、類別、設計、實體化方式)

   d. 使用共通性和可變性分析抽象出行為和資料中的變化。

   e. 依介面設計。

   f. 將繼承看成一種將變化概念化的方法，而不是建立已有物件的特殊情形。

   g. 將變化放入一個類別中，並與該類別中的其他變化解耦。

   h. 力求鬆耦合。

   i. 力求強內聚。

   j. 將使用一個物件的程式碼與建立該物件的程式碼分離。

   k. 在應用「一次且僅此一次」規則時要絕對小心。(p109)

   l. 透過「依意圖程式設計」，使用反應意圖的名字，確保程式碼的可讀性。(p110)

   m. 在程式設計之前就考慮程式碼的可測試性。(p110)

79.依責任分解問題領域。(p335)

80.Alexander：「在這最後階段，模式不再重要...模式已經教會了你對真實的感悟力。」(p337)