有了翅膀才能飞， 欠缺灵活的代码就象冻坏了翅膀的鸟儿。不能飞翔，就少了几许灵动的气韵。我们需要给代码带去温暖的阳光， 让僵冷的翅膀重新飞起来。
结合实例， 通过应用OOP、设计模式和重构，你会看到代码是怎样一步一步复活的。
为了更好的理解设计思想， 实例尽可能简单化。 但随着需求的增加，程序将越来越复杂。
此时就有修改设计的必要， 重构和设计模式就可以派上用场了。 最后当设计渐趋完美后，你会发现， 即使需求不断增加，你也可以神清气闲，不用为代码设计而烦恼了。
假定我们要设计一个媒体播放器。 该媒体播放器目 前只支持音频文件 mp3 和 wav。
如果不谈设计， 设计出来的播放器可能很简单：
1 public class MediaPlayer
2 {
3 private void PlayMp3()
4 {
5 MessageBox.Show("Play the mp3 file.");
6 }
7 private void PlayWav()
8 {
9 MessageBox.Show("Play the wav file.");
10 }
11 public void Play(string audioType)
12 {
13 switch (audioType.ToLower())
14 {
15 case ("mp3"):
16 PlayMp3();
17 break;
18 case ("wav"):
19 PlayWav();
20 break;
21 }
22 }
23 }
简单的播放器实现代码
自然，你会发现这个设计非常的糟糕。 因为它根本没有为未来的需求变更提供最起码的扩展。
如果你的设计结果是这样， 那么当你为应接不暇的需求变更而焦头烂额的时候， 你可能更希望让这份设计到它应该去的地方， 就是桌面的回收站。
仔细分析这段代码， 它其实是一种最古老的面向结构的设计。 如果你要播放的不仅仅是 mp3 和 wav,你会不断增加相应地播放方法， 然后让 switch 子句越来越长， 直至达到你视线看不到的地步。
好吧，我们先来体验对象的精神。根据OOP的思想，我们应该吧mp3和wav看作是一个队里的对象，那么是这样吗：
1 public class MP3
2 {
3 public void Play()
4 {
5 MessageBox.Show("Play the mp3 file.");
6 }
7 }
8 public class WAV
9 {
10 public void Play()
11 {
12 MessageBox.Show("Play the wav file.");
13 }
14 }
提取MP3和WAV类
好样的，你已经知道怎么建立对象了。更可喜的是，你在不知不觉中应用了重构的方法，把原来那个垃圾设计中的方法名字改为了统一的Play()方法。你在后面的设计中，会发现这样改名是多么的关键！
但似乎你并没有击中要害，以现在的方式去更改MediaPlayer的代码，实质并没有多大的变化。
既然mp3和wav都属于音频文件，他们都具有音频文件的共性，为什么不为他们建立一个共同的父类呢：
1 public class AudioMedia
2 {
3 public void Play()
4 {
5 MessageBox.Show("Play the AudioMedia file.");
6 }
7 }
提取父类AudioMedia.cs
现在我们引入了继承的思想， OOP 也算是象模象样了。
得意之余， 还是认真分析现实世界吧。 其实在现实生活中， 我们播放的只会是某种具体类型的音频文件， 因此这个AudioMedia 类并没有实际使用的情况。对应在设计中， 就是： 这个类永远不会被实例化。
所以， 还得动一下手术， 将其改为抽象类。 好了， 现在的代码有点 OOP 的感觉了：
1 public abstract class AudioMedia
2 {
3 public abstract void Play();
4 }
5 public class MP3 : AudioMedia
6 {
7 public override void Play()
8 {
9 MessageBox.Show("Play the mp3 file.");
10 }
11 }
12 public class WAV : AudioMedia
13 {
14 public override void Play()
15 {
16 MessageBox.Show("Play the wav file.");
17 }
18 }
19 public class MediaPlayer
20 {
21 public void Play(AudioMedia media)
22 {
23 media.Play();
24 }
25 }
将父类改为抽象类后的结构
看看现在的设计， 即满足了类之间的层次关系， 同时又保证了类的最小化原则， 更利于扩展（到这里，你会发现 play 方法名改得多有必要）。
即使你现在又增加了对 WMA 文件的播放， 只需要设计 WMA 类， 并继承 AudioMedia，重写 Play 方法就可以了， MediaPlayer类对象的 Play 方法根本不用改变。是不是到此就该画上圆满的句号呢？
然后刁钻的客户是永远不会满足的， 他们在抱怨这个媒体播放器了。因为他们不想在看足球比赛的时候， 只听到主持人的解说， 他们更渴望看到足球明星在球场奔跑的英姿。
也就是说， 他们希望你的媒体播放器能够支持视频文件。你又该痛苦了， 因为在更改硬件设计的同时， 原来的软件设计结构似乎出了问题。 因为视频文件和音频文件有很多不同的地方， 你可不能偷懒， 让视频文件对象认音频文件作父亲啊。
你需要为视频文件设计另外的类对象了， 假设我们支持 RM 和 MPEG 格式的视频：
1 public abstract class VideoMedia
2 {
3 public abstract void Play();
4 }
5 public class RM : VideoMedia
6 {
7 public override void Play()
8 {
9 MessageBox.Show("Play the rm file.");
10 }
11 }
12 public class MPEG : VideoMedia
13 {
14 public override void Play()
15 {
16 MessageBox.Show("Play the mpeg file. ");
17 }
18 }
另外设计视频播放类
糟糕的是， 你不能一劳永逸地享受原有的 MediaPlayer 类了。 因为你要播放的 RM 文件并不是 AudioMedia 的子类。
不过不用着急， 因为接口 这个利器你还没有用上（虽然你也可以用抽象类， 但在 C#里只支持类的单继承）。虽然视频和音频格式不同， 别忘了， 他们都是媒体中的一种，很多时候， 他们有许多相似的功能， 比如播放。
根据接口的定义，你完全可以将相同功能的一系列对象实现同一个接口：
1 public interface IMedia
2 {
3 void Play();
4 }
5 public abstract class AudioMedia : IMedia
6 {
7 public abstract void Play();
8 }
9 public abstract class VideoMedia : IMedia
10 {
11 public abstract void Play();
12 }
提取视频与音频的接口
再更改一下 MediaPlayer 的设计就 OK 了：
1 public class MediaPlayer
2 {
3 public void Play(IMedia media)
4 {
5 media.Play();
6 }
7 }
现在可以总结一下，从 MediaPlayer 类的演变，我们可以得出这样一个结论：在调用类对象的属性和方法时， 尽量避免将具体类对象作为传递参数， 而应传递其抽象对象， 更好地是传递接口， 将实际的调用和具体对象完全剥离开，这样可以提高代码的灵活性。
不过， 事情并没有完。 虽然一切看起来都很完美了， 但我们忽略了这个事实， 就是忘记了 MediaPlayer 的调用者。
还记得文章最开始的 switch 语句吗？ 看起来我们已经非常漂亮地除掉了这个烦恼。事实上，我在这里玩了一个诡计， 将 switch 语句延后了。虽然在 MediaPlayer中， 代码显得干净利落， 其实烦恼只不过是转嫁到了 MediaPlayer 的调用者那里。
例如， 在主程序界面中：
1 public void BtnPlay_Click(object sender, EventArgs e)
2 {
3 IMedia media;
4 switch (cbbMediaType.SelectItem.ToString().ToLower())
5 {
6 case ("mp3"):
7 media = new MP3();
8 break;
9 case ("wav"):
10 media = new WAV();
11 break;
12 //其它类型略；
13 }
14 MediaPlayer player = new MediaPlayer();
15 player.Play(media);
16 }
点击“播放”按钮
用户通过选择 cbbMediaType 组合框的选项，决定播放哪一种文件， 然后单击 Play 按钮执行。现在该设计模式粉墨登场了，这种根据不同情况创建不同类型的方式， 工厂模式是最拿手的。
先看看我们的工厂需要生产哪些产品呢 ？ 虽然这里有两种不同类型的媒体AudioMedia 和 VideoMedia（以后可能更多）， 但它们同时又都实现 IMedia 接口，所以我们可以将其视为一种产品，用工厂方法模式就可以了。
首先是工厂接口：
1 public interface IMediaFactory
2 {
3 IMedia CreateMedia();
4 }
然后为每种媒体文件对象搭建一个工厂， 并统一实现工厂接口：
1 public class MP3MediaFactory : IMediaFactory
2 {
3 public IMedia CreateMedia()
4 {
5 return new MP3();
6 }
7 }
8 public class RMMediaFactory : IMediaFactory
9 {
10 public IMedia CreateMedia()
11 {
12 return new RM();
13 }
14 }
15 //其它工厂略；
写到这里， 也许有人会问， 为什么不直接给 AudioMedia 和 VideoMedia 类搭建工厂呢？
很简单， 因为在 AudioMedia 和 VideoMedia 中， 分别还有不同的类型派生， 如果为它们搭建工厂， 则在 CreateMedia()方法中， 仍然要使用 Switch语句。而且既然这两个类都实现了 IMedia接口 ，可以认为是一种类型， 为什么还要那么麻烦去请动抽象工厂模式， 来生成两类产品呢？
可能还会有人问， 即使你使用这种方式， 那么在判断具体创建哪个工厂的时候， 不是也要用到 switch 语句吗？
我承认这种看法是对的。不过使用工厂模式， 其直接好处并非是要解决 switch 语句的难题， 而是要延迟对象的生成， 以保证的代码的灵活性。 当然，我还有最后一招杀手锏没有使出来，到后面你会发现， switch 语句其实会完全消失。还有一个问题， 就是真的有必要实现 AudioMedia 和 VideoMedia 两个抽象类吗？ 让其子类直接实现接口 不更简单？ 对于本文提到的需求，我想你是对的， 但不排除 AudioMedia 和VideoMedia 它们还会存在区别。
例如音频文件只需要提供给声卡的接口， 而视频文件还需要提供给显卡的接口。 如果让 MP3、 WAV、 RM、 MPEG 直接实现 IMedia 接口， 而不通过AudioMedia 和 VideoMedia， 在满足其它需求的设计上也是不合理的。 当然这已经不包括在本文的范畴了。
现在主程序界面发生了稍许的改变：
public void BtnPlay_Click(object sender, EventArgs e)
{
IMediaFactory factory = null;
switch (cbbMediaType.SelectItem.ToString().ToLower())
{
case ("mp3"):
factory = new MP3MediaFactory();
break;
case ("wav"):
factory = new WAVMediaFactory();
break;
//其他类型略；
}
MediaPlayer player = new MediaPlayer();
player.Play(factory.CreateMedia());
}
写到这里， 我们再回过头来看 MediaPlayer 类。
这个类中，实现了 Play 方法， 并根据传递的参数， 调用相应媒体文件的 Play 方法。 在没有工厂对象的时候， 看起来这个类对象运行得很好。
如果是作为一个类库或组件设计者来看， 他提供了这样一个接口， 供主界面程序员调用。 然而在引入工厂模式后， 在里面使用 MediaPlayer 类已经多余了。
所以，我们要记住的是， 重构并不仅仅是往原来的代码添加新的内容。 当我们发现一些不必要的设计时， 还需要果断地删掉这些冗余代码。
1 public void BtnPlay_Click(object sender, EventArgs e)
2 {
3 IMediaFactory factory = null;
4 switch (cbbMediaType.SelectItem.ToString().ToLower())
5 {
6 case ("mp3"):
7 factory = new MP3MediaFactory();
8 break;
9 case ("wav"):
10 factory = new WAVMediaFactory();
11 break;
12 //其他类型略；
13 }
14 IMedia media = factory.CreateMedia();
15 media.Play();
16 }
如果你在最开始没有体会到 IMedia 接口 的好处， 在这里你应该已经明白了。我们在工厂中用到了该接口； 而在主程序中， 仍然要使用该接口 。使用接口有什么好处？那就是你的主程序可以在没有具体业务类的时候， 同样可以编译通过。因此， 即使你增加了新的业务，你的主程序是不用改动的。
不过， 现在看起来，这个不用改动主程序的理想， 依然没有完成。看到了 吗？在BtnPlay_Click()中， 依然用 new 创建了一些具体类的实例。
如果没有完全和具体类分开， 一旦更改了具体类的业务，例如增加了新的工厂类， 仍然需要改变主程序， 何况讨厌的 switch语句仍然存在， 它好像是翅膀上滋生的毒瘤， 提示我们， 虽然翅膀已经从僵冷的世界里复活，但这双翅膀还是有病的， 并不能正常地飞翔。
是使用配置文件的时候了。我们可以把每种媒体文件类类型的相应信息放在配置文件中， 然后根据配置文件来选择创建具体的对象。 并且，这种创建对象的方法将使用反射来完成。
首先， 创建配置文件：
1 <appSettings> 2 <add key="mp3" value="WingProject.MP3Factory" /> 3 <add key="wav" value="WingProject.WAVFactory" /> 4 <add key="rm" value="WingProject.RMFactory" /> 5 <add key="mpeg" value="WingProject. MPEGFactory" /> 6 </appSettings>
然后， 在主程序界面的 Form_Load 事件中， 读取配置文件的 所有 key 值， 填充cbbMediaType 组合框控件：
1 public void Form_Load(object sender, EventArgs e)
2 {
3 cbbMediaType.Items.Clear();
4 foreach (string key in ConfigurationSettings.AppSettings.AllKeys)
5 {
6 cbbMediaType.Item.Add(key);
7 }
8 cbbMediaType.SelectedIndex = 0;
9 }
最后， 更改主程序的 Play 按钮单击事件：
1 public void BtnPlay_Click(object sender, EventArgs e)
2 {
3 string mediaType = cbbMediaType.SelectItem.ToString().ToLower();
4 string factoryDllName = ConfigurationSettings.AppSettings[mediaType].ToString();
5 //MediaLibray为引用的媒体文件及工厂的程序集;
6 IMediaFactory factory = (IMediaFactory)Activator.CreateInstance
7 ("MediaLibrary", factoryDllName).Unwrap();
8 IMedia media = factory.CreateMedia();
9 media.Play();
10 }
现在鸟儿的翅膀不仅仅复活，有了可以飞的能力；同时我们还赋予这双翅膀更强的功能，它可以飞得更高， 飞得更远！享受自由飞翔的惬意吧。
设想一下， 如果我们要增加某种媒体文件的播放功能， 如 AVI文件。 那么， 我们只需要在原来的业务程序集中创建 AVI 类， 并实现 IMedia 接口 ， 同时继承 VideoMedia 类。
另外在工厂业务中创建 AVIMediaFactory 类， 并实现 IMediaFactory 接口。
假设这个新的工厂类型为 WingProject.AVIFactory， 则在配置文件中添加如下一行：
<add key="avi" value="WingProject.AVIFactory" />
而主程序呢？ 根本不需要做任何改变， 甚至不用重新编译，这双翅膀照样可以自 如地飞行！
《设计之道》学习笔记