编程成长之路何尝不是这样的呢？
故事就是从这里开始的。
小王是刚毕业的学生，进入一家软件公司，薪水不错。年轻人充满干劲，有着远大的目标。前三天参加了公司的培训，三天没写代码了，手痒。第四天，项目经理走过来说：“小王，写一个整型链表的排序算法吧，我们在项目中要用。”
冒泡是小王在脑海中第一个浮现出来的。翻开某某圣经，摘了段冒泡算法，修改了一些代码的书写风格（有些圣经代码风格不咱的），代码大致如此：
BOOL Sort(ListInt)
{
冒泡排序算法
{
比较语句
}
return TRUE；
}
小王检查了一下，还用测试用例测试了一把，确保万无一失，交给了经理。经理说了句不错，乐坏了小王。
第二天，经理跑过来说：“把你昨天的代码改一下，现在要比较浮点型了，还有能否速度上提高一点？”
小王上网查了一下，选择了快速排序算法，不忘把昨天写的备份了一把，然后在昨天函数的基础上改。代码大致如此：
BOOL Sort(ListFloat)
{
快速排序算法
{
比较语句
}
return TRUE；
}
Easy吗？测试交差。
一年后……
镜头切换……
小王坐在计算机前熟练的编写着程序，而且旁边还放着本《设计模式》的书。知道了面向对象编程，知道了设计模式，但理解还不够深刻。排序算法也演变成比较文件名了。
一日经理过来说：“小王，现在我们的排序算法要用在嵌入式平台中，你做一些算法的研究工作，给出一份报告。”
这不是策略模式的典型应用吗？定义一系列的算法，把它们一个个封装起来，并且使他们可以相互转换。
小王画了张UML图：
这样，小王把一些流行的排序算法都试了一遍，总共有七八种，换一种算法修改也很方便，新的算法插入到系统中，老算法从系统中"退休"，实现插件式替换。
CSort *pSort ＝ new CBubbleSort;
CClient.ListSort(pSort);
如果要改成快速排序，只要如此：
CSort *pSort ＝ new CQuickSort;
CClient.ListSort(pSort);
测试交差，当然经理自己也有想法，又让小王试了另外的几个算法，小王都能轻松的完成。策略模式的作用在这里淋漓尽致的发挥了，小王心里特别有成就感。
过了些日子，客户提出需要按文件名、日期进行排序，小王觉得这还是比较简单的，更改了一下UML图：
改代码的主要工作是copy-paste，就四个函数，也就很快完成了。
客户的需求是不会停止的，为了加强功能，提出需要按文件大小、文件的类型排序，天知道客户还会提出什么要求。
“再也不能这样活”，小王听着歌，陷入了沉思。
“排序的算法和比较算法分开来会如何呢？把它们脱耦，使得二者可以独立地变化。这句话怎么这么熟悉，我肯定在哪里看到过。”小王忙翻开《设计模式》，开始查阅。
“Got it，这不就是桥梁模式（Bridge）。”一阵欣喜，马上就干。半个小时后，UML图出来了，如下：
客户端代码如下：
CSort *pSort = new CQuickSort;
CCompareType *pType = new CNameCompare;
pSort->SetType(pType);
pSort->Sort(pList);
哈哈，客户们，你们尽管提要求吧。
又一年……
镜头切换……
今天就写到这里了，下回接着分解，如果有兴趣的人可以接着故事说说，看看和我下面的想法是否一样。这种方法对学习设计模式挺好的。
