《利用C++模板技术支持多种计算策略》由会员分享，可在线阅读，更多相关《利用C++模板技术支持多种计算策略（8页珍藏版）》请在金锄头文库上搜索。
1、武汉理工大学 孟岩 任何有经验的程序员和软件设计师都知道，在软件开发中最常见的困境的并不是在问题 面前束手无策，而是在一大堆好像都可行的解决策略中选择一个。软件设计就是选择的过程， 其困难之处也就在于你得不断地、小心翼翼地做出各种选择。在传统的程序设计模式下，每 一次选择都是不可逆转的，你做出了选择，那么随后的开发都将会受到这次选择的剧烈影响。 当你发现自己当初的选择错误的时候，可能一切都已经为时太晚。这有点像是走迷宫，而走 迷宫时如果你发觉走进了死胡同，还可以掉头换一条路线。但在软件开发中，更换计算策略 的成本太高，几乎是无法承受的。如果能够有一种软件设计方法，使更换计算策略的成本大 大降低
2、，使你有更多的“悔棋”的机会，那么软件设计的难度就可以大大降低，质量就会得 到很大的提高。另一个常常出现而且令人烦恼的问题是这样的，我们在软件的开发中经常会遇到同类型 的问题反复地以不同面貌出现，每次都让你在直觉上感到这几个问题好像差不多。但是当你 满怀信心的企图实现一个可重用组件，一劳永逸地解决问题的时候，你就会沮丧地发现，一 些细节上的不同使你很难、甚至根本没有办法实现这样一个可重用的组件。于是你不得不一 次次地重写类似的代码，使得程序冗长，难于维护。如果我们有一种高度抽象的软件开发技 术，把所有细节上的不同都抽象起来，包装在一个统一的接口背后，那么我们就有能力来达 成更高程度的代码可重用
3、性，写出适用性更强的软件组件。显然，在这些细节里，类型是一 个重要方面，而另一个重要方面就是计算策略。综合这两点，我们可以看到，把计算策略从一个软件组件中抽象出来将会非常有益。这 当然不是一件容易的事情，不光需要在设计上做大量分析，还需要一些特别的编程技术。本 文试图用C+提供的模板技术，来给出解决这个问题的一种思路。1. 一个实际例子我拿一个手头的例子来说明，在施工进度控制系统里，有一个这样的功能：在已知各种 必要信息的情况下，需要估算进行某项工作需要花费的时间。在这里，我的角色不是应用程 序的开发者，而是支持组件的开发者。也就是说，我来提供组件，由客户程序员具体使用， 完成特定的任务。在这
4、样一个简单的任务里，充满了各种选择，我们把这些选择简述如下：基本计算模型：可以采用经验估计法，也可以用公式计算法，用户还可能有其他更贴切 的计算模型。精确度要求：通常只有两个选项，一是采用精确计算，二是采用模糊数学理论处理。环境干扰因素的影响（天气、气候等）：可以按照最理想、最糟糕、历年平均和今年预 计四种计算策略处理，用户还可能有其他的选项。其实还可以找出一些策略，但是用来说明问题，上面给出的足够了，单在这里就总共提供了2*2*4 = 16种策略组合。作为组件开发者，我不可能知道客户程序员在开发应用软件时需要用什么样的策略组 合。在形成早期计划时，需要理想估算，可以用公式计算法+精确计算+历
5、年平均策略组合。 在施工过程中，经验来得更重要一些，需要用经验估算法+模糊计算+今年预计这个组合形 式，施工单位还可能想知道自己最好和最差的情形，也许还会用到预期自然状况为最理想和 最糟糕的计算策略。总之，写这个组件的时候我根本不知道应用开发者会怎样使用它，具体 的策略组合只有到面对具体问题时才能由应用开发者做出决定，我不能替他们提前做决断， 我的任务是必须不折不扣地提供全部的组合可能。怎么办？将这 16 种不同方案逐一写来？上面的任何一个策略只要多出一个选择项，组 合数目就增加数个，更有甚者，如果突然你发现还需要再多考虑一个因素，比如工作者执行 计划的能力因素，那么组合方案会几倍增加。这太可
6、怕了。计算机科学界有一句名言：“永 远不要对抗组合爆炸。”所以，我们必须设法重用代码。现在我把问题归纳如下：需要设计一种方案来实现一个叫做 WorkingTimeEstimater 的可重用组件，可以根据使用 这个组件的客户程序员的意志自由地组合各种计算策略，并表现出相应的行为。2. 利用多态性我们理想的情况是这样的，写一个WorkingTimeEstimater类，在这个类中间有一个成员 函数estimate。，用来算出当前工序的耗时，这个类大致的框架看起来像这个样子：class WorkingTimeEstimate public:const Time estimate();/计算当前工序
7、耗时，返回表示时间的Time值private:listWorkProc& works_;/WorkPro代表一个工序，works_是准备/计算的一系列工序 list:iterator型参数。但是，如果这个假设不成立， 比如 StatAlgo:CalcBasicAlgo()声明为：TimeStatAlgo:CalcBasicAlgo(list:iteratoriter,const StatInfo& si);那么我们就会遇到很大的麻烦。AbstractAlgo:CalcBasicAlgo()的函数签名应该是 什么？怎么写 WorkingTimeEstimate:estimate()?即使现在没有出现这个问题，如果 以后要向 AbstractAlgo 类层次里加入新的派生类，也难免遇到问题。我们该怎么设 计一个“强壮”的基类？这个问题恐怕困扰过每一个设计过OOP程序的人，从而得 了一个专门的名字：fragile base class (脆弱的基类)。上面的一些问题，是不是让你感到没有希望了呢？其实也不是没希望，仍旧在OOP领 域里，仍旧利用 polymorphism 机制，我们总能够想到一些办法来解决这些问题。比如，我 们禁止所有的策略类在 heap 中建立对象，
