UML软件工程组织

成长的烦恼:初涉设计模式
作者: goodcandle
  相信很多人都喜欢看这部喜剧,我是很喜欢,里面包括了成长中的悲欢离合,你在其中可以寻找你成长的足迹。

  编程成长之路何尝不是这样的呢?

  故事就是从这里开始的。

  小王是刚毕业的学生,进入一家软件公司,薪水不错。年轻人充满干劲,有着远大的目标。前三天参加了公司的培训,三天没写代码了,手痒。第四天,项目经理走过来说:“小王,写一个整型链表的排序算法吧,我们在项目中要用。”

  冒泡是小王在脑海中第一个浮现出来的。翻开某某圣经,摘了段冒泡算法,修改了一些代码的书写风格(有些圣经代码风格不咱的),代码大致如此:

       
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);

        哈哈,客户们,你们尽管提要求吧。
 

版权所有:UML软件工程组织