GotW #15 Class Relationships Part II
著者：Herb Sutter
翻译：kingofark
[声明]：本文内容取自www.gotw.ca网站上的Guru of the Week栏目，其著作权归原著者本人所有。译者kingofark在未经原著者本人同意的情况下翻译本文。本翻译内容仅供自学和参考用，请所有阅读过本文的人不要擅自转载、传播本翻译内容；下载本翻译内容的人请在阅读浏览后，立即删除其备份。译者kingofark对违反上述两条原则的人不负任何责任。特此声明。
Revision 1.0
Guru of the Week 条款15：类之间的关系（下篇）
难度：6 / 10
（设计模式是编写可复用代码的一个重要工具。你能辨认出本条款中的代码所用到的模式吗？你能改进它吗？）
[问题]
一个操纵数据库的程序经常需要在一个给定的表（table）中对一条或多条纪录（record）施以一定的操作。这一般涉及到两个连续的过程：首先以只读方式游访（pass through）整个表以搜集信息，确定哪些纪录需要被操纵；然后再对表进行第二次游访，实施真正的操作。
为了避免每次重复的编写那些惯常使用的操作代码，一个程序员试图通过下面的抽象类来提供一个通用的可复用框架（framework）。他希望抽象类能通过如下方式来封装那些重复的代码：首先，生成一个清单（list），用来记录表中需要被处理的那些记录行（record row）；其次，对清单中的每个表项进行相应的处理。各种特定的处理代码细节由各个派生类自己实现。
//---------------------------------------------------
// gta.h 文件
//---------------------------------------------------
class GenericTableAlgorithm {
public:
GenericTableAlgorithm( const string& table );
virtual ~GenericTableAlgorithm();
// Process() 如果执行成功就返回true.
// 它做了所有的工作，包括: a) physically reads
// a)从物理设备上读取表中的记录，然后对每一条记录调用Filter()
// 来检查其是否就是需要被处理的记录；
// b)当创建好需要被处理的记录的清单后，对每一条需要被处理的记录
// 调用ProcessRow()。
bool Process();
private:
// 如果当前记录就是需要被处理的记录，Filter() 就返回true。
// 缺省的行为是将表中的所有记录都包括进去。
virtual bool Filter( const Record& ) {
return true;
}
// 对每一条需要被处理的记录，ProcessRow()被调用一次。
// 这正是实际使用的特定的类中进行其特定的操作的地方。
// （注意：可以看出，每一条记录前前后后被读取了两次。
// 这里我们假设出现这种情况是必要的，而不是一个效率上的问题。）
virtual bool ProcessRow( const PrimaryKey& ) =0;
class GenericTableAlgorithmImpl* pimpl_; // MYOB
};
这个类的使用者从其派生出一个类，可能会像下面这样编写使用代码：
class MyAlgorithm : public GenericTableAlgorithm {
// ... 在这里覆写Filter()和ProcessRow()，进行一些
// 特定的具体操作...
};
int main( int, char*[] ) {
MyAlgorithm a( "Customer" );
a.Process();
}
现在有3个问题：
1． 这是一个不错的设计，它实现了一种常用的设计模式（design patterns）。请问，这里使用的是什么模式？为什么这种模式可以用在这里？
2． 在不改变其本设计的情况下，评估这种设计被实际执行的方式。你能采用一些与其不一样的方式吗？pimpl_成员是为什么而设计的？
3． 实际上，这个设计可以进行较大的改进。GenericTableAlgorithm所担负的责任是什么？如果其担负的责任多于一个，那么这些责任所包含的操作应该如何被更好的封装起来？说明你采用的方法是如何影响类的可复用性的，特别是类的可扩展性这方面。
[解答]
1． 这是一个不错的设计，它实现了一种常用的设计模式（design patterns）。请问，这里使用的是什么模式？为什么这种模式可以用在这里？
这种模式叫做Template Method（可别跟C++中的template模板搞混淆了）。[注1] 这种设计模式非常有用，因为我们由此可以从算法中提取出那些每次都要进行的步骤，将其抽象出来，只把一些因地制宜的细节留给派生类来实现。
（注意：pimpl_惯用法与
Bridge方法非常相似[注1]，但在这里，它只是作为一种对抗编译依赖性的防火墙而存在；它将各个特定类的具体实现细节隐藏起来，其在运作的时候与真正的具有可扩展性的
bridge还不太一样。）
2． 在不改变其本设计的情况下，评估这种设计被实际执行的方式。你能采用一些与其不一样的方式吗？pimpl_成员是为什么而设计的？
这个设计里面使用bool变量作为返回值，同时也丧失了使用其它方法——例如状态码（status code）或者异常处理——来进行错误报告（error reporting）的能力。也许根据依照某些特定的需求来考虑的时候，这样做是不错的，但一般我们还是应该认识并注意到这一点。
那个（不太容易发音的）pimpl_成员很好的将实现细节隐藏在了一个神秘的指针后面。pimpl_所指向的结构包含了私有成员函数和成员变量。这样一来，对他们进行任何改变，都不用重新编译用户代码（client code）。这正是Lakos等人[注2]所描述的一种很重要的技术。之所以说很重要，是因为这种技术在不给代码带来过多的复杂性和干扰的情况下，从一定程度上弥补了C++缺少模块系统（module system）的不足。
3． 实际上，这个设计可以进行较大的改进。GenericTableAlgorithm所担负的责任是什么？如果其担负的责任多于一个，那么这些责任所包含的操作应该如何被更好的封装起来？
GenericTableAlgorithm还可以进行较大的改进，因为他现在还是身兼二职。这就跟普通人在身兼二职时需要承受额外的负担一样，压力会很大。所以我们可以想见，缓解和改变GenericTableAlgorithm这种身兼二职、一心两用的状况，一定会对类自身大有好处。
在原始代码中，GenericTableAlgorithm担负着两个完全不同且毫不相关的责任。这两个责任完全可以被有效的分离开来，这是因为它们面向着不同的作用对象。简单的说，这两种责任是：
（1） 用户代码（client code）使用特定的通用算法（generic algorithm）；
（2） 针对特定的实际情况，GenericTableAlgorithm会使用具有特定实现细节的类来使其操作特殊化（specialize）。
好，该说的说完了，现在我们来看看改进之后的代码：
//---------------------------------------------------
// gta.h文件
//---------------------------------------------------
// 责任#1: 提供一个公共接口，使其能够将常用的功能作为
// template method进行封装。这与继承关系无关，并可以
// 在一个实现特定功能的类中被很好的孤立起来。这是一个面向
// GenericTableAlgorithm的外部用户（external users）
// 的接口。
class GTAClient;
class GenericTableAlgorithm {
public:
// 构造函数现在获取了一个有具体实现的对象。
GenericTableAlgorithm( const string& table,
GTAClient& worker );
// 由于我们把继承关系隔离了起来，因此析构函数不必是virtual的。
// 事实上，我们也许压根儿就不需要它。
~GenericTableAlgorithm();
bool Process(); // 这一行不变
private:
class GenericTableAlgorithmImpl* pimpl_; // MYOB
};
//---------------------------------------------------
// gtaclient.h文件
//---------------------------------------------------
// 责任 #2: 为可扩展性提供了一个抽象接口。在这里，
// GenericTableAlgorithm的实现细节与外部用户代码无关，
// 并且可以被隔离到一个作用更明确的抽象协议类中去。
// 这里的接口是面向那些利用GenericTableAlgorithm 来编写
//可被实际使用的类的代码编写者。
class GTAClient {
public:
virtual ~GTAClient() =0;
virtual bool Filter( const Record& ) {
return true;
}
virtual bool ProcessRow( const PrimaryKey& ) =0;
};
可以看到，上面的两个类需要放在不同的头文件里面。那么在经过了这些改变之后，用户代码（client code）又可能会是什么样子的呢？答案是，用户代码（client code）基本没有变化，与原来的几乎一样：
class MyWorker : public GTAClient {
// ... 在这里覆写Filter()和ProcessRow()，进行一些
// 特定的具体操作...
};
int main( int, char*[] ) {
GenericTableAlgorithm a( "Customer", MyWorker() );
a.Process();
}
尽管代码样子没怎么变，但是必须考虑改进之后产生的如下三个效果：
1． 如果GenericTableAlgorithm的公共接口改变了会怎么样？结果是：在原始的版本中，所有具体的用户端的类都需要被重新编译，这是因为它们都派生自GenericTableAlgorithm；而在改进的版本中，对GenericTableAlgorithm公共接口的任何改变都被很好的孤立起来了，并不会影响用户端所使用的具体的类。
2． 如果GenericTableAlgorithm的可扩展协议被改变了会怎么样（比如Filter()或Processrow()里增加了新的缺省参数）？结果是：在原始的版本中，即使GenericTableAlgorithm公共接口没有任何改变，所有使用GenericTableAlgorithm的外部代码都必须被重新编译。这是因为，一个派生接口（derivation interface）在类定义中是可见的。而在改进的版本中，对GenericTableAlgorithm扩展协议接口的任何改变都被很好的孤立起来了，并不影响外部的用户代码。
3． 在改进的版本中，任何具体被使用的类可以在任何以Filter()或Processrow()为接口的算法中被使用，而不仅仅限于GenericTableAlgorithm中。
其实，我们在改进的代码中使用了与Strategy Pattern[注1]极为相似的模式（pattern）。
要记住计算机科学领域中的一句格言：Most any problem can be solved by adding a level of indirection（大部分问题可以通过增加间接层次即间接性来解决）。当然，同时考虑“奥卡的剃刀（Occam's Razor）” 原则也是很明智的。“奥卡的剃刀（Occam's Razor）”原则说道：Don't multiply entities more than necessary（不要做超出需求的额外举动）。把握好这两者之间的平衡关系，可以使你在花费很少甚至免费的情况下，增强代码的可复用性和可维护性——这无论如何都是一笔划算的买卖。
你也许注意到了，GenericTableAlgorithm其实完全可以是一个函数（实际上，有些人会把Process()改称为operator()()，这是由于此时的类很明显的只是一个functor（函算符）而已）。这里的类之所以可以替换成函数，是因为这里并没有说明在调用Process()的前后需要保存状态。例如我们可以把代码替换成这样：
bool GenericTableAlgorithm(
const string& table,
GTAClient& method ) {
// ... 原来的Process() 放在在这里...
}
int main( int, char*[] ) {
GenericTableAlgorithm( "Customer", MyWorker() );
}
这里的代码实际上就是一个通用函数（generic function），可以根据实际需要将其特殊化（specialized）。如果你发现“method”对象并不需要保存状态信息（），你就可以使“method”对象成为一个non-class template parameter（非class的模板参数）：
template<typename GTACworker>
bool GenericTableAlgorithm( const string& table ) {
// ... 原来的Process() 放在在这里...
}
int main( int, char*[] ) {
GenericTableAlgorithm<MyWorker>( "Customer" );
}
这一个函数版本只比上面那个少了一个逗号。当然，在本条款所讨论的问题里面，少这一个逗号并不会给你带来多大的好处，因此第一个函数或许更好些。毕竟，能够抵挡住诱惑，不去编写这样一些以炫耀为目的的蹊跷的代码，总是一件好事。
无论如何，选择使用函数实现还是使用类实现完全取决于你要达到的目的。在本条款的这个问题中，使用函数实现比较好。
[注1]：E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995)。（中文版：《设计模式：可复用面向对象软件的基础》）
[注2]：J. Lakos. Large-Scale C++ Software Design (Addison-Wesley, 1996)。
（完）
