成长的烦恼：初涉设计模式

下载本文示例代码
　　相信很多人都喜欢看这部喜剧，我是很喜欢，里面包括了成长中的悲欢离合，你在其中可以寻找你成长的足迹。 编程成长之路何尝不是这样的呢？　　故事就是从这里开始的。　　小王是刚毕业的学生，进入一家软件公司，薪水不错。年轻人充满干劲，有着远大的目标。前三天参加了公司的培训，三天没写代码了，手痒。第四天，项目经理走过来说：“小王，写一个整型链表的排序算法吧，我们在项目中要用。”　　冒泡是小王在脑海中第一个浮现出来的。翻开某某圣经，摘了段冒泡算法，修改了一些代码的书写风格（有些圣经代码风格不咱的），代码大致如此： BOOL Sort(ListInt) { 冒泡排序算法 { 比较语句 } return TRUE； }　　小王检查了一下，还用测试用例测试了一把，确保万无一失，交给了经理。经理说了句不错，乐坏了小王。　　第二天，经理跑过来说：“把你昨天的代码改一下，现在要比较浮点型了，还有能否速度上提高一点？”　　小王上网查了一下，选择了快速排序算法，不忘把昨天写的备份了一把，然后在昨天函数的基础上改。代码大致如此： BOOL Sort(ListInt) { 快速排序算法 { 比较语句 } 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); 哈哈，客户们，你们尽管提要求吧。 　　相信很多人都喜欢看这部喜剧，我是很喜欢，里面包括了成长中的悲欢离合，你在其中可以寻找你成长的足迹。 编程成长之路何尝不是这样的呢？　　故事就是从这里开始的。　　小王是刚毕业的学生，进入一家软件公司，薪水不错。年轻人充满干劲，有着远大的目标。前三天参加了公司的培训，三天没写代码了，手痒。第四天，项目经理走过来说：“小王，写一个整型链表的排序算法吧，我们在项目中要用。”　　冒泡是小王在脑海中第一个浮现出来的。翻开某某圣经，摘了段冒泡算法，修改了一些代码的书写风格（有些圣经代码风格不咱的），代码大致如此： BOOL Sort(ListInt) { 冒泡排序算法 { 比较语句 } return TRUE； }　　小王检查了一下，还用测试用例测试了一把，确保万无一失，交给了经理。经理说了句不错，乐坏了小王。　　第二天，经理跑过来说：“把你昨天的代码改一下，现在要比较浮点型了，还有能否速度上提高一点？”　　小王上网查了一下，选择了快速排序算法，不忘把昨天写的备份了一把，然后在昨天函数的基础上改。代码大致如此： BOOL Sort(ListInt) { 快速排序算法 { 比较语句 } 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); 哈哈，客户们，你们尽管提要求吧。 下载本文示例代码


成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式成长的烦恼：初涉设计模式