首先會看懂UML

UML類圖與類的關係詳解

虛線箭頭指向依賴；
實線箭頭指向關聯；
虛線三角指向介面；
實線三角指向父類；
空心菱形能分離而獨立存在，是聚合；
實心菱形精密關聯不可分，是組合；

上面是UML的語法。
在畫類圖的時候，理清類和類之間的關係是重點。類的關係有泛化(Generalization)、實現（Realization）、依賴(Dependency)和關聯(Association)。其中關聯又分為一般關聯關係和聚合關係(Aggregation)，合成關係(Composition)。下麵我們結合實例理解這些關係。註意【代碼表現】裡面的描述！

設計模式分類

創建型模式

單件模式
抽象工廠
建造者模式
工廠方法模式
原型模式

結構型模式

適配器模式
橋接模式
組合模式
裝飾模式
外觀模式
享元模式
代理模式

行為型模式

職責鏈模式
命令模式
解釋器模式
迭代器模式
中介者模式
備忘錄模式
觀察者模式
狀態模式
策略模式
模版方法
訪問者模式

設計模式案例

比如《組合模式》的UML圖

意圖

將對象組合成樹形結構以表示“部分-整體”的層次結構。Composite 使得用戶對單個對象和組
合對象的使用具有一致性。

適用性

• 你想表示對象的部分-整體層次結構。
• 你希望用戶忽略組合對象與單個對象的不同，用戶將統一地使用組合結構中的所有對象。

根據UML中的【代碼表現】寫出對應示例代碼

// Composite pattern -- Structural example
using System;
using System.Collections;
namespace DoFactory.GangOfFour.Composite.Structural
{
    // MainApp test application
    class MainApp
    {
        static void Main()
        {
            // Create a tree structure
            Composite root = new Composite("root");
            root.Add(new Leaf("Leaf A"));
            root.Add(new Leaf("Leaf B"));
            Composite comp = new Composite("Composite X");
            comp.Add(new Leaf("Leaf XA"));
            comp.Add(new Leaf("Leaf XB"));
            root.Add(comp);
            root.Add(new Leaf("Leaf C"));
            // Add and remove a leaf
            Leaf leaf = new Leaf("Leaf D");
            root.Add(leaf);
            root.Remove(leaf);
            // Recursively display tree
            root.Display(1);
            // Wait for user
            Console.Read();
        }
    }
    // "Component"
    abstract class Component
    {
        protected string name;
        // Constructor
        public Component(string name)
        {
            this.name = name;
        }
        public abstract void Add(Component c);
        public abstract void Remove(Component c);
        public abstract void Display(int depth);
    }
    // "Composite"
    class Composite : Component
    {
        private ArrayList children = new ArrayList();
        // Constructor
        public Composite(string name) : base(name)
        {
        }
        public override void Add(Component component)
        {
            children.Add(component);
        }
        public override void Remove(Component component)
        {
            children.Remove(component);
        }
        public override void Display(int depth)
        {
            Console.WriteLine(new String('-', depth) + name);
            // Recursively display child nodes
            foreach (Component component in children)
            {
                component.Display(depth + 2);
            }
        }
    }
    // "Leaf"
    class Leaf : Component
    {
        // Constructor
        public Leaf(string name) : base(name)
        {
        }
        public override void Add(Component c)
        {
            Console.WriteLine("Cannot add to a leaf");
        }
        public override void Remove(Component c)
        {
            Console.WriteLine("Cannot remove from a leaf");
        }
        public override void Display(int depth)
        {
            Console.WriteLine(new String('-', depth) + name);
        }
    }
}

 總結

設計模式的主要思想其實很簡單，就是：測試驅動開發。測試先行。意思是：先寫測試代碼，再去實現代碼。
所以先寫單元測試是很重要的，因為選用什麼設計模式，不是容易就決定的。還是根據業務場景去決定的。而且業務需求隨時都變
化。所以你的代碼要經受得住各種變化。設計模式跟著需求變化而變化。這就是XP的關鍵，擁抱變化。那如何確保每次修改後代碼
能穩定地運行呢？那就行寫好單元測試。儘量覆蓋儘量多的測試用例，每次修改完跑一下單元測試。不用管要用什麼設計模式。只
要你的代碼都能通過，你的代碼肯定用了很多設計模式在裡面，不然不可能做到擁抱變化（就是解耦）。設計模式的目標就是擁抱變化。

總結內容參考博文 https://www.cnblogs.com/wolf12/p/8736290.html

打賞

 本文鏈接 https://www.cnblogs.com/smartstar/p/10823694.html