C#设计模式大全.doc

C#设计模式（1） 4
一、 C# 面向对象程序设计复习 5
二、 设计模式举例 5
三、 先有鸡还是先有蛋？ 7
四、 大瓶子套小瓶子还是小瓶子套大瓶子？ 8
五、 .net本质 9
C#设计模式（2） 11
一、 "开放－封闭"原则(OCP) 12
二、 里氏代换原则（LSP） 12
C#设计模式（3） 19
三、 依赖倒置原则(DIP) 19
四、 接口隔离原则（ISP） 20
五、 合成/聚合复用原则（CARP） 21
六、 迪米特法则（LoD） 22
C#设计模式（4）－Simple Factory Pattern 24
一、 简单工厂（Simple Factory）模式 24
二、 Simple Factory模式角色与结构： 24
三、 程序举例： 25
四、 Simple Factory模式演化 27
五、 优点与缺点： 29
C#设计模式（5）－Factory Method Pattern 30
一、 工厂方法（Factory Method）模式 30
二、 Factory Method模式角色与结构： 30
三、 程序举例： 31
四、 工厂方法模式与简单工厂模式 33
五、 Factory Method模式演化 34
六、 Factory Method模式与其它模式的关系 35
七、 另外一个例子 35
C#设计模式（6）－Abstract Factory Pattern 38
一、 抽象工厂（Abstract Factory）模式 38
二、 Abstract Factory模式的结构： 39
三、 程序举例： 41
四、 在什么情形下使用抽象工厂模式： 44
五、 抽象工厂的起源 45
六、 Abstract Factory模式在实际系统中的实现 46
七、 "开放－封闭"原则 50
C#设计模式（7）－Singleton Pattern 50
一、 单例（Singleton）模式 50
二、 Singleton模式的结构： 51
三、 程序举例： 51
四、 在什么情形下使用单例模式： 52
五、 Singleton模式在实际系统中的实现 53
六、 C#中的Singleton模式 55
C#设计模式（8）－Builder Pattern 57
一、 建造者（Builder）模式 57
二、 Builder模式的结构： 58
三、 程序举例： 58
四、 建造者模式的活动序列： 62
五、 建造者模式的实现： 62
六、 建造者模式的演化 68
七、 在什么情况下使用建造者模式 69
C#设计模式（9）－Prototype Pattern 70
一、 原型（Prototype）模式 70
二、 Prototype模式的结构： 71
三、 程序举例： 71
四、 带Prototype Manager的原型模式 73
五、 浅拷贝与深拷贝 77
六、 Prototype模式的优点与缺点 79
C#设计模式（10）－Adapter Pattern 80
一、 适配器（Adapter）模式 80
二、 类的Adapter模式的结构： 81
三、 类的Adapter模式示意性实现： 81
四、 对象的Adapter模式的结构： 83
五、 对象的Adapter模式示意性实现： 84
六、 在什么情况下使用适配器模式 85
七、 一个实际应用Adapter模式的例子 85
八、 关于Adapter模式的讨论 87
C#设计模式（11）－Composite Pattern 88
一、 合成（Composite）模式 88
二、 合成模式概述 88
三、 安全式的合成模式的结构 90
四、 安全式的合成模式实现 91
五、 透明式的合成模式结构 93
六、 透明式的合成模式实现 94
七、 使用合成模式时考虑的几个问题 97
八、 和尚的故事 98
九、 一个实际应用Composite模式的例子 98
C#设计模式（12）－Decorator Pattern 101
一、 装饰（Decorator）模式 101
二、 装饰模式的结构 102
三、 装饰模式示例性代码 103
四、 装饰模式应当在什么情况下使用 106
五、 装饰模式实际应用的例子 106
六、 使用装饰模式的优点和缺点 110
七、 模式实现的讨论 111
八、 透明性的要求 111
九、 装饰模式在.NET中的应用 112
C#设计模式（13）－Proxy Pattern 113
一、 代理（Proxy）模式 113
二、 代理的种类 114
三、 远程代理的例子 114
四、 代理模式的结构 115
五、 代理模式示例性代码 115
六、 高老庄悟空降八戒 117
七、 不同类型的代理模式 118
八、 代理模式实际应用的例子 119
设计模式（14）－Flyweight Pattern 122
一、 享元（Flyweight）模式 122
二、 单纯享元模式的结构 122
三、 单纯享元模式的示意性源代码 123
四、 复合享元模式的结构 125
五、 一个咖啡摊的例子 127
六、 咖啡屋的例子 130
七、 享元模式应当在什么情况下使用 133
八、 享元模式的优点和缺点 134
设计模式（15）－Facade Pattern 134
一、 门面（Facade）模式 134
二、 门面模式的结构 134
三、 门面模式的实现 135
四、 在什么情况下使用门面模式 135
五、 一个例子 136
六、 使用门面模式的设计 140
设计模式（16）－Bridge Pattern 144
一、 桥梁（Bridge）模式 144
二、 桥梁模式的结构 145
三、 桥梁模式的示意性源代码 146
四、 调制解调器问题 149
五、 另外一个实际应用Bridge模式的例子 153
六、 在什么情况下应当使用桥梁模式 158
设计模式（17）－Chain of Responsibility Pattern 158
一、 职责链（Chain of Responsibility）模式 160
二、 责任链模式的结构 160
三、 责任链模式的示意性源代码 160
四、 纯的与不纯的责任链模式 163
五、 责任链模式的实际应用案例 163
六、 责任链模式的实现 168
设计模式（18）－Command Pattern 168
一、 命令（Command）模式 168
二、 命令模式的结构 168
三、 命令模式的示意性源代码 169
四、 玉帝传美猴王上天 172
五、 命令模式的实现 172
六、 命令模式的实际应用案例 173
七、 在什么情况下应当使用命令模式 177
八、 使用命令模式的优点和缺点 178
设计模式（19）－Observer Pattern 178
一、 观察者（Observer）模式 178
二、 观察者模式的结构 179
三、 观察者模式的示意性源代码 180
四、 C#中的Delegate与Event 183
五、 一个实际应用观察者模式的例子 187
六、 观察者模式的优缺点 191
设计模式（20）－Visitor Pattern 192
一、 访问者（Visitor）模式 192
二、 访问者模式的结构 193
三、 示意性源代码 194
四、 一个实际应用Visitor模式的例子 198
五、 在什么情况下应当使用访问者模式 202
六、 使用访问者模式的优点和缺点 203
设计模式（21）－Template Method Pattern 204
一、 模板方法（Template Method）模式 204
二、 模版方法模式的结构 204
三、 模板方法模式的示意性代码 205
四、 继承作为复用的工具 207
五、 一个实际应用模板方法的例子 208
六、 模版方法模式中的方法 210
七、 重构的原则 211
设计模式（22）－Strategy Pattern 211
一、 策略（Strategy）模式 211
二、 策略模式的结构 212
三、 示意性源代码 212
四、 何时使用何种具体策略角色 215
五、 一个实际应用策略模式的例子 215
六、 在什么情况下应当使用策略模式 218
七、 策略模式的优点和缺点 218
八、 其它 219
C#设计模式（1）

课本：《C#设计模式》，电子工业出版社，ISBN 7-5053-8979-3。33元含光盘。
课程内容：设计模式
来源：亚历山大的建筑模式、Gamma等人（1995）创作的"Design Patterns: Elements of Reusable Software"。这本书通常被称作"Gang of Four"或"GoF"，开创性的创造了《设计模式》。
也有人说"三十六计"就是"模式"。

一、 C# 面向对象程序设计复习
  点击

  字段与属性.cs
  属性、方法作用范围.cs
  一加到一百.cs
  使用接口排序(2).cs
  使用接口排序(1).cs
  求质数.cs
  冒泡法排序.cs
  九九表.cs
  静态与非静态.cs
  构造函数.cs
  方法重载.cs
  多态性.cs
  递归求阶乘.cs
  打印三角形.cs
  传值调用与引用调用.cs

二、 设计模式举例
在设计模式中有一种模式叫Builder模式，其原理如下：
我们可以将Builder理解成电饭锅，给这个Builder放进去米和水，经过Builder的Build后，我们就可以取出香喷喷的米饭了。
C#中有一个类叫StringBuilder，输入必要的信息后，就可以取出对应的String。其使用方法如下：
using System;
using System.Text;

class Exam
{
 public static void Main()
 {
  StringBuilder sb = new StringBuilder();
  sb.Append('a',2);
  sb.Append('b',3);
  sb.Append('c',4);
  Console.WriteLine(sb.ToString()); //打印出 aabbbcccc
  sb.Remove(0, sb.Length); //清除sb中的所有信息
 }
}
程序执行结果为： aabbbcccc
请使用StringBuilder对以下打印三角型的程序进行改写，写出新程序。
using System;
public class Exam
{
 public static void Main()
 {
  Console.Write("请输入行数:");
  int lines = int.Parse(Console.ReadLine());
  Console.WriteLine("");
  for(int i=1; i<=lines ; i++)
  {
   for(int k=1; k<= lines-i; k++)
    Console.Write(" ");
   for(int j=1; j<=i*2-1; j++)
    Console.Write("*");
   Console.WriteLine("");
  }
}
}
答：
using System;
using System.Text;
class Exam
{
 public static void Main()
 {
  Console.Write("请输入行数:");
  int lines = int.Parse(Console.ReadLine());
  Console.WriteLine("");

  StringBuilder sb = new StringBuilder();

  for(int i=1; i<=lines ; i++)
  {
   sb.Append(' ', lines-i);
   sb.Append('*', i*2-1);
   Console.WriteLine(sb.ToString());
   sb.Remove(0, sb.Length);
  }
 }
}

三、 先有鸡还是先有蛋？
到底是先有鸡还是先有蛋？看下面的代码：
using System;

class Client
{
   public static void Main ()
   {
      Base b = new Base();
      Derived d = new Derived();
      b.d = d;
      Console.WriteLine(b.d.m);      
   }
}

class Base
{
   public int n = 9;
   public Derived d;
}

class Derived : Base
{
   public int m = 10;   
}
Derived继承自Base，可以说没有Base就没有Derived，可Base里面有一个成员是Derived类型。到底是先有鸡还是先有蛋？这个程序可以正常编译执行并打印结果10。

四、 大瓶子套小瓶子还是小瓶子套大瓶子？
另外一个例子：
using System;

class Client
{
   public static void Main ()
   {
      A a = new A();
      B b = new B();
      a.b = b;
      b.a = a;
   }
}

class A
{
   public B b;
}

class B
{
   public A a; 
}
上面的代码似乎描述了"a包含b，b包含a"的关系，到底是大瓶子套小瓶子还是小瓶子套大瓶子呢？

五、 .net本质
关于"先有鸡还是先有蛋"的程序，系统运行后，内存结构如下：

由图中可以看出，根本不存在鸡与蛋的问题，而是型与值的问题以及指针引用的问题。
关于"大瓶子套小瓶子还是小瓶子套大瓶子"问题，系统运行后，内存结构如下：

由于是指针引用，所以也无所谓大瓶子还是小瓶子了。
关于更多内容可以参考《.NET本质论 第1卷：公共语言运行库》。

C#设计模式（2）
《人月神话》焦油坑、没有银弹

* 软件腐化的原因：
问题所在   设计目标
----------------------------------------------------------------------------
过于僵硬   可扩展性（新性能可以很容易加入系统）
过于脆弱   灵活性（修改不会波及其它）
复用率低  
粘度过高   可插入性（新功能容易加入系统（气囊加入方向盘））
* 提高系统可复用性的几点原则：
传统复用：
1. 代码的粘帖复用
2. 算法的复用
3. 数据结构的复用
* 可维护性与可复用性并不完全一致
* 对可维护性的支持：

一、 "开放－封闭"原则(OCP)
Open-Closed Principle原则讲的是：一个软件实体应当对扩展开放，对修改关闭。
优点：
    通过扩展已有软件系统，可以提供新的行为，以满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。
    已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
例子：玉帝招安美猴王
当年大闹天宫便是美猴王对玉帝的新挑战。美猴王说："'皇帝轮流做，明年到我家。'只教他搬出去，将天宫让于我！"对于这项挑战，太白金星给玉皇大帝提出的建议是："降一道招安圣旨，宣上界来…，一则不劳师动众，二则收仙有道也。"
换而言之，不劳师动众、不破坏天规便是"闭"，收仙有道便是"开"。招安之道便是玉帝天庭的"开放－封闭"原则。

招安之法的关键便是不允许更改现有的天庭秩序，但允许将妖猴纳入现有秩序中，从而扩展了这一秩序。用面向对象的语言来讲，不允许更改的是系统的抽象层，而允许更改的是系统的实现层。

二、 里氏代换原则（LSP）
Liskov Substitution Principle（里氏代换原则）：子类型(subtype)必须能够替换它们的基类型。
白马、黑马

反过来的代换不成立
《墨子·小取》说："娣，美人也，爱娣，非爱美人也……"娣便是妹妹，哥哥喜爱妹妹，是因为两人是兄妹关系，而不是因为妹妹是个美人。因此，喜爱妹妹不等同于喜爱美人。用面向对象语言描述，美人是基类，妹妹是美人的子类。哥哥作为一个有"喜爱()"方法，接受妹妹作为参数。那么，这个"喜爱()"方法一般不能接受美人的实例。

一个违反LSP的简单例子（长方形和正方形）
public class Rectangle
{
   private long width;
   private long height;

   public void setWidth(long width)
   {
      this.width = width;
   }
   public long getWidth()
   {
      return this.width;
   }
   public void setHeight(long height)
   {
      this.height = height;
   }
   public long getHeight()
   {
      return this.height;
   }
}

public class Square
{
   private long side;

   public void setSide(long side)
   {
      this.side = side;
   }

   public long getSide()
   {
      return side;
   }
}

正方形不可以做长方形的子类
using System;

public class Rectangle
{
   private long width;
   private long height;

   public void setWidth(long width)
   {
      this.width = width;
   }
   public long getWidth()
   {
      return this.width;
   }
   public void setHeight(long height)
   {
      this.height = height;
   }
   public long getHeight()
   {
      return this.height;
   }
}

public class Square : Rectangle
{
   private long side;

   public void setWidth(long width)
   {
      setSide(width);
   }

   public long getWidth()
   {
      return getSide();
   }

   public void setHeight(long height)
   {
      setSide(height);
   }

   public long getHeight()
   {
      return getSide();
   }

   public long getSide()
   {
      return side;
   }

   public void setSide(long side)
   {
      this.side = side;
   }
}

public class SmartTest
{
   public void resize(Rectangle r)
   {
      while (r.getHeight() >= r.getWidth() )
      {
         r.setWidth(r.getWidth() + 1);
      }
   }
}

在执行SmartTest的resize方法时，如果传入的是长方形对象，当高度大于宽度时，会自动增加宽度直到超出高度。但是如果传入的是正方形对象，则会陷入死循环。
代码重构
public interface Quadrangle
{
   public long getWidth();
   public long getHeight();
}

public class Rectangle : Quadrangle 
{
   private long width;
   private long height;

   public void setWidth(long width)
   {
      this.width = width;
   }
   public long getWidth()
   {
      return this.width;
   }
   public void setHeight(long height)
   {
      this.height = height;
   }
   public long getHeight()
   {
      return this.height;
   }
}

public class Square : Quadrangle 
{
   private long side;

   public void setSide(long side)
   {
      this.side = side;
   }

   public long getSide()
   {
      return side;
   }

   public long getWidth()
   {
      return getSide();
   }

   public long getHeight()
   {
      return getSide();
   }
}

 C#设计模式（3）
三、 依赖倒置原则(DIP)
依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。
简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：
抽象不应当依赖于细节；细节应当依赖于抽象；
要针对接口编程，不针对实现编程。
反面例子：

缺点：耦合太紧密，Light发生变化将影响ToggleSwitch。
解决办法一：
将Light作成Abstract，然后具体类继承自Light。

优点：ToggleSwitch依赖于抽象类Light，具有更高的稳定性，而BulbLight与TubeLight继承自Light，可以根据"开放－封闭"原则进行扩展。只要Light不发生变化，BulbLight与TubeLight的变化就不会波及ToggleSwitch。
缺点：如果用ToggleSwitch控制一台电视就很困难了。总不能让TV继承自Light吧。
解决方法二：

优点：更为通用、更为稳定。
结论：
使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。
四、 接口隔离原则（ISP）
接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
My object-oriented umbrella（摘自Design Patterns Explained）
Let me tell you about my great umbrella. It is large enough to get into! In fact, three or four other people can get in it with me. While we are in it, staying out of the rain, I can move it from one place to another. It has a stereo system to keep me entertained while I stay dry. Amazingly enough, it can also condition the air to make it warmer or colder. It is one cool umbrella.
My umbrella is convenient. It sits there waiting for me. It has wheels on it so that I do not have to carry it around. I don't even have to push it because it can propel itself. Sometimes, I will open the top of my umbrella to let in the sun. (Why I am using my umbrella when it is sunny outside is beyond me!)
In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors. Most people call them cars.
实现方法：
1、 使用委托分离接口
2、 使用多重继承分离接口
五、 合成/聚合复用原则（CARP）
合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）经常又叫做合成复用原则（Composite Reuse Principle或CRP），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。
简而言之，要尽量使用合成/聚合，尽量不要使用继承。
o Design to interfaces.
o Favor composition over inheritance.
o Find what varies and encapsulate it.
（摘自：Design Patterns Explained）
区分"Has-A"与"Is-A"
"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，它表示某一个角色具有某一项责任。
导致错误的使用继承而不是合成/聚合的一个常见的原因是错误的把"Has-A"当作"Is-A"。
例如：

实际上，雇员、经理、学生描述的是一种角色，比如一个人是"经理"必然是"雇员"，另外一个人可能是"学生雇员"，在上面的设计中，一个人无法同时拥有多个角色，是"雇员"就不能再是"学生"了，这显然是不合理的。
错误源于把"角色"的等级结构与"人"的等级结构混淆起来，误把"Has-A"当作"Is-A"。解决办法：

六、 迪米特法则（LoD）
迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP），也就是说，一个对象应当对其它对象有尽可能少的了解。
其它表述：
  只与你直接的朋友们通信
  不要跟"陌生人"说话
  每一个软件单位对其它的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
迪米特法则与设计模式
Facade模式、Mediator模式
使民无知
《老子》第三章曰："是以圣人之治，虚其心，实其腹，弱其志，常使民无知无欲。"使被"统治"的对象"愚昧"化，处于"无知"的状态，可以使"统治"的成本降低。
所谓"最少知识"原则，实际上便是老子的"使民无知"的统治之术。
不相往来
《老子》云："小国寡民……邻国相望，鸡犬之声相闻，民至老死，不相往来。"将被统治的对象隔离开来，使它们没有直接的通信，可以达到分化瓦解，继而分而治之的效果。迪米特法则与老子的"小国寡民"的统治之术不谋而合。

C#设计模式（4）－Simple Factory Pattern
工厂模式专门负责将大量有共同接口的类实例化。工厂模式可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。工厂模式有以下几种形态：
· 简单工厂（Simple Factory）模式
· 工厂方法（Factory Method）模式
· 抽象工厂（Abstract Factory）模式

一、 简单工厂（Simple Factory）模式
Simple Factory模式根据提供给它的数据，返回几个可能类中的一个类的实例。通常它返回的类都有一个公共的父类和公共的方法。
Simple Factory模式实际上不是GoF 23个设计模式中的一员。

二、 Simple Factory模式角色与结构：

工厂类角色Creator (LightSimpleFactory)：工厂类在客户端的直接控制下（Create方法）创建产品对象。

抽象产品角色Product (Light)：定义简单工厂创建的对象的父类或它们共同拥有的接口。可以是一个类、抽象类或接口。

具体产品角色ConcreteProduct (BulbLight, TubeLight)：定义工厂具体加工出的对象。

三、 程序举例：

using System;

public abstract class Light
{
   public abstract void TurnOn();
   public abstract void TurnOff();
}

public class BulbLight : Light
{
   public override void TurnOn()
   {
      Console.WriteLine("Bulb Light is Turned on");
   }

   public override void TurnOff()
   {
      Console.WriteLine("Bulb Light is Turned off");
   }
}

public class TubeLight : Light
{
   public override void TurnOn()
   {
      Console.WriteLine("Tube Light is Turned on");
   }

   public override void TurnOff()
   {
      Console.WriteLine("Tube Light is Turned off");
   }
}

public class LightSimpleFactory
{
   public Light Create(string LightType)
   {
      if(LightType == "Bulb")
         return new BulbLight();
      else if(LightType == "Tube")
         return new TubeLight();
      else
         return null;
   }
}

public class Client
{
   public static void Main()
   {
      LightSimpleFactory lsf = new LightSimpleFactory();

      Light l = lsf.Create("Bulb");
      l.TurnOn();
      l.TurnOff();

      Console.WriteLine("-----------------");

      l = lsf.Create("Tube");
      l.TurnOn();
      l.TurnOff();
   }
}

四、 Simple Factory模式演化
Simple Factory模式演化（一）
除了上面的用法外，在有些情况下Simple Factory可以由抽象产品角色扮演，一个抽象产品类同时是子类的工厂。

程序举例：
using System;

public class Light
{
   public virtual void TurnOn()
   {
   }

   public virtual void TurnOff()
   {
   }

   public static Light Create(string LightType)
   {
      if(LightType == "Bulb")
         return new BulbLight();
      else if(LightType == "Tube")
         return new TubeLight();
      else
         return null;
   }
}

public class BulbLight : Light
{
   public override