下载本文示例代码
又一年…… 镜头切换…… 因为小王平时的出色表现，现在小王也是小小的项目经理了。而身边又多了一本书《重构：改善改善既有代码的设计》。排序的算法也相对稳定下来，排序也成为一个独立的模块，很多的地方中都使用到了。然而需求又变了，说要使用冒泡排序算法。“我的天啊，为何不早说呢？现在这么多地方都用到了。”小王查找了一下，总共有15处使用了相同的代码。代码的腐臭味。“以后还要增加，怎么办？以后还要换排序算法怎么办？”毕竟现在的小王不是以前的水平了，遇到问题都会三思而后行。一个声音在呼唤：“用工厂方法（Factory Method）吧。”长痛不如短痛，对代码进行重构。UML图如下：
在客户端程序一开始就初始化工厂：
CSortFactory* pSortFactory = new CBubbleSortFactory; 然后把所有调用的地方改成如下的代码：
CSort *pSort = pSortFactory->Create();CCompareType *pType = new CNameCompare;pSort->SetType(pType);pSort->Sort(pList); 化了半个小时，把15处地方都修改过来。这样做的好处你知道了吗？以后如果发展到50处地方使用，难道你还一处一处去修改吗？Keep in your mind，需求是不断变化的。现在如果要改算法，只要修改一处就行，就是把CBubbleSortFactory替换掉。 这样真的彻底地解决问题了吗？掌握主动权就是掌握了命运。经过三年的磨练，小王处处长了个心眼，防患与未然。 这里有一个不稳定的因素就是Compare Type，难道它不会变化了？其实上面的代码应该是这样的：
CSort *pSort = pSortFactory->Create();if(nType == SortName) CCompareType *pType = new CNameCompare;else if(nType == SortDate) CCompareType *pType = new CDateCompare;else CCompareType *pType = new CSizeCompare; pSort->SetType(pType);pSort->Sort(pList); 小王不能容忍这种隐患，使用一个简单工厂模式（Simple Factory）吧。“发现变化，封装它。”UML图如下：
把if-else，switch移到CSimpleCompareFactory的Create函数中去吧。在客户端程序初始化代码加上一句：
CSimpleCompareFactory *pSimpleFactory = new CSimpleCompareFactory; 调用地方的代码改为：
CSort *pSort = pSortFactory->Create();CCompareType *pType = pSimpleFactory ->Create(nSortName);pSort->SetType(pType);pSort->Sort(pList); “if-else，switch语句不是还在吗？”一个声音在问。 “怎么这么多问题？难道if-else，switch语句不能用吗？”有时不必强求，只要做到改动最小就行了，程序的代码在大部分情况下是能做修改的。 上面的设计已经能解决大部分的扩展的。 然而日子还在继续，客户还在提需求，小王还在继续自己的梦想。
又一年…… 镜头切换…… 因为小王平时的出色表现，现在小王也是小小的项目经理了。而身边又多了一本书《重构：改善改善既有代码的设计》。排序的算法也相对稳定下来，排序也成为一个独立的模块，很多的地方中都使用到了。然而需求又变了，说要使用冒泡排序算法。“我的天啊，为何不早说呢？现在这么多地方都用到了。”小王查找了一下，总共有15处使用了相同的代码。代码的腐臭味。“以后还要增加，怎么办？以后还要换排序算法怎么办？”毕竟现在的小王不是以前的水平了，遇到问题都会三思而后行。一个声音在呼唤：“用工厂方法（Factory Method）吧。”长痛不如短痛，对代码进行重构。UML图如下：
在客户端程序一开始就初始化工厂：
CSortFactory* pSortFactory = new CBubbleSortFactory; 然后把所有调用的地方改成如下的代码：
CSort *pSort = pSortFactory->Create();CCompareType *pType = new CNameCompare;pSort->SetType(pType);pSort->Sort(pList); 化了半个小时，把15处地方都修改过来。这样做的好处你知道了吗？以后如果发展到50处地方使用，难道你还一处一处去修改吗？Keep in your mind，需求是不断变化的。现在如果要改算法，只要修改一处就行，就是把CBubbleSortFactory替换掉。 这样真的彻底地解决问题了吗？掌握主动权就是掌握了命运。经过三年的磨练，小王处处长了个心眼，防患与未然。 这里有一个不稳定的因素就是Compare Type，难道它不会变化了？其实上面的代码应该是这样的：
CSort *pSort = pSortFactory->Create();if(nType == SortName) CCompareType *pType = new CNameCompare;else if(nType == SortDate) CCompareType *pType = new CDateCompare;else CCompareType *pType = new CSizeCompare; pSort->SetType(pType);pSort->Sort(pList); 小王不能容忍这种隐患，使用一个简单工厂模式（Simple Factory）吧。“发现变化，封装它。”UML图如下：
把if-else，switch移到CSimpleCompareFactory的Create函数中去吧。在客户端程序初始化代码加上一句：
CSimpleCompareFactory *pSimpleFactory = new CSimpleCompareFactory; 调用地方的代码改为：
CSort *pSort = pSortFactory->Create();CCompareType *pType = pSimpleFactory ->Create(nSortName);pSort->SetType(pType);pSort->Sort(pList); “if-else，switch语句不是还在吗？”一个声音在问。 “怎么这么多问题？难道if-else，switch语句不能用吗？”有时不必强求，只要做到改动最小就行了，程序的代码在大部分情况下是能做修改的。 上面的设计已经能解决大部分的扩展的。 然而日子还在继续，客户还在提需求，小王还在继续自己的梦想。
下载本文示例代码
成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式成长的烦恼：进一步理解设计模式
阅读(145) | 评论(0) | 转发(0) |
