OOAD 及 UML 學習筆記

交流QQ群:26651479

day01:
物件導向
    通過封裝、繼承、多態，把程式的耦合度降低，使程式靈活、容易修改、容易複用。
    物件導向=對象 + 類 + 訊息 + 繼承 + 多態
    物件導向方法是一種把物件導向的思想運用於軟體開發過程，指導開發活動的系統方法，包括分析、設計和實現等活動

    軟體開發組越大，組中每個成員的生產率就越低
                    --Philippe Kahn, Borland
       Ln = 15000/(n^-3)( LOC / year )
       構造大型軟體不能靠堆人

    敏捷開發：
        1. 思路先行  //先用注釋把思路記錄下來
        2. 實現隨後

  可維護性：預見需求(預見多年後的事)
  可重用：
          代碼可重用(最低層級)：粒度：方法(常用代碼塊)，類，包，組件(類庫)
          設計的可重用：架構(半成品，如Hibernate)；產品(開發軟體)；演算法、設計模式
          分析的可重用(最進階別，見不到代碼)：文檔、規範、標準(ISO：CMM，CMMI)
  可擴充性：

UML圖
    類(class) 用矩形框表示，分三層
        第一層：類名，抽象類別用斜體字
        第二層：類的特性：欄位和屬性
        第三層：類的操作：方法或行為
             方法前的符號：“+”表示public，“-”表示private，“#”表示protected

    介面：右邊的“飛翔”
        頂端有<<interface>>，第一層是介面名字，第二層是方法
    介面的另一種標記法：俗稱棒棒糖標記法，就是類上面的一根棒棒糖(圓圈+實線)
        圓圈旁為介面名稱，介面方法在實作類別中出現

    繼承：用空心三角+實線
    實現介面：空心三角+虛線

 

類與對象之間的關係(6種)：
    關聯 Association：一個類受另一個類影響(實線)
    彙總關聯 Aggregation：弱'擁有'關係，A對象可以包含B對象，但B不是A的一部分(空心菱形+實線箭頭)［DPE］
        (DPE 表示這句話來自《設計模式》)
    組合關聯 Composition：(也叫合成，組成)是一種強的‘擁有’關係，體現嚴格的部分和整體的關係，
        部分和整體的生命週期一樣［DPE］(實心菱形+實線箭頭)
      組合圖形的基數：表明這一端的類可以有幾個執行個體，(一隻鳥有兩個翅膀)如果有無數個執行個體，則用n表示
        關聯關係、彙總關係也可以有基數
    依賴 Dependency ：一個類需要另外一個類(X需要Y，則X的修改Y也要跟著修改) (虛線箭頭)
    泛化(繼承) (實心菱形+實線)
    實現  (實心菱形+虛線)
  

 

UML 4+1 圖
    1：使用案例圖    描述系統中有哪些使用者可用的功能
    4：邏輯圖    將問題中的一些名詞提取出來，形成系統中對應的類，表示之間的關係。
       過程圖    表示系統對象間的互動
       實現圖    系統中組件與組件之間互動
       部署圖    軟體系統真實運行過程的物理描述

 

靜態(系統結構)：
        類圖
        對象圖
        構建圖
        部署圖
動態(系統行為)：
        順序圖    (時序圖)
        共同作業圖表
        狀態圖
        活動圖表
        使用案例圖
  

 

 

day02:
物件導向的7大基本設計原則

程式設計：沒有最好，只有最適合。尋找平衡點。

1. LSP(The Liskov Substitution Principle ,替換原則)
父類出現的地方，子類都可出現。
子類或實作類別與父類都是可以互換的。
    子類不能添加任何父類沒有的附加約束
    子類對象必須可以替換父類對象

2. OCP (The Open-Close Principle,開閉原則)
要關聯抽象，不要關聯具體，抽象可擴充。
    擴充是開放的，更改是封閉的

3. SRP(The Single Responsibility Principle,單一職責原則)
依賴不同的具體類，不要將不相關的方法放到一個具體類中，然後具體類再關聯。
    一個類，應該僅有一個引起它變化的原因
    當需求變化時，該變化會反映為類的職責的變化(如果有多個職責，引起變化的原因就會有多個)

4. ISP(The Interface Segregation Principle,介面隔離原則)
具體類不要實現無關介面中的方法，應使用具體類實現多個介面。
    避免肥介面，以一個類實現多個介面，而各客戶僅僅獲知必須的介面
    本質：
        使用多個專門的介面比使用單一的介面好
        一個類對另一個類的依賴性應當最小化
        避免介面汙染(Interface Pollution)(使用不必要的功能)

5. DIP(The Dependency Inversion Principle,依賴倒置原則)
高層依賴於抽象，底層繼承/實現於抽象。
    高層模組不應該依賴於低層模組，二者都應該依賴於抽象
    細節應該依賴於抽象，而抽象不應該依賴於細節
    針對介面編程，不是針對實現編程

6. CARP(Composite/Aggregate Reuse Principle,組合/彙總複用原則)
盡量使用組合/彙總，而不是使用繼承來達到複用目的
    繼承的缺點：會帶來不必要的方法
    組合/彙總的解決方案
        組合：部分的更改會影響整體的生命
        彙總：部分的更改對整體的影響不大

7. LoD(Law of Demeter,迪米特法則)
類間最少通訊原則，採用中間類。
    也稱最少知識原則。一個對象或模組應該和其它對象和模組盡量少的通訊

 

GoF(Gang of Fout) 23種經典設計模式
        建立型                     結構型               行為型
類   Factory Method Factory 方法     Adapter_Class       Interpreter
                                                   Template Method
對象 Abstract Factory 抽象工廠   Adapter_Object      Chain of Responsibility
    Builder                    Bridge              Command
    Prototype 原型              Composite           Iterator
    Singleton 單例              Decorator 裝飾       Mediator
                               Facade              Memento
                               Flyweight           Observer
                               Proxy               State    狀態
                                                   Strategy
                                                   Visitor

單例模式:
    當多個對象需要共用同一個對象時;
原型模式:
    對擴充開發,對修改關閉;
原廠模式:
    客戶需要某個產品,能夠根據客戶要求取得產品給客戶;
狀態模式:
    當需要對某個對象內部狀態改變時,使用;
裝飾模式:
    當需要對某個對象動態添加新功能時,可以用;
適配器模式:
    只需要對介面中的一小部分方法重新定義,又不希望將介面中的所有方法實現,
    這時可以使用;
觀察者模式:
    當主題對象改變時,需要通知所有的觀察者,這時可以使用;
命令模式:
    將使用者發出命令以對象形式傳遞,通過參數可改變命令對象的狀態;