使用vs2005(vc8)编译log4cpp-0.3.5rc3

不在同一个包内的参与者、用例、类、构件和包，名称可以相同。不同的模型元素拥有相同的名称时，这些元素被称为“重载”
重载允许你进行基于多语言构件的开发。
重载允许用例视图中的参与者和逻辑视图中的类拥有相同的名称

创建一个重载元素
1）从工具箱中创建一个新的元素
2）双击新元素，或者单击Browse>Specification，打开规范窗口
3）在名称字段中输入名称
4）单击OK按钮 

如果在其它包中存在具有相同名称的设计元素，系统会提示你，此时点“确定”即可

逻辑视图:描述系统设计模型，包含与系统结构最重要意义的部分，比如，系统分解成为的子系统，子系统分解成多个类，以及这些元素的职责，关系，操作和属性

进程视图：描述系统分解成线程及进程的过程，描述线程（进程）通讯模试等

部署视图：描述运行系统的物理硬件（包含网络）配置，说明每个节点的计算机，CPU，操作系统以及它们互联的情况，还要包括进程到节点之间的映射关系。

实施视图：描述系统在构建时的分解后的子系统（包）的情况，特别是包括哪些组成部分由哪些团队开发，以及购入，外包，开发进度等内容。项目经理应该对这个视图最感兴趣。

Customers, who need to be sure that the system that is getting built is the one that they want.
客户，他们需要确定即将构建的系统是他们需要的系统。

Managers, who need to have an overall understanding of what the system will do in order to effectively plan and monitor the project.

经理，他们需要对将着手的系统有一个全局的了解，以便于对项目有效的计划和监控。

Analysts, who need to describe and document what the system is going to do.
分析员，他们需要对将要着手的系统进行描述和文档化。

Developers, who need to understand what the system needs to do in order to develop it.
开发人员，他们需要理解系统以便于开发它。

Tester， who need to know what the system is supposed to do so that  they can verify that is does it.
测试人员，他们需要知道期望系统实现的功能，以便于它们验证系统是执行这些功能。

Technical writers,who need to know what the system is supposed to so that they can describe it.
支持文档撰写者，他们需求要知道期望的系统以例描述它。
 
User-experience designers, who need to understand the users' goals and how the will use the system to achieve these goals.

用户体验设计人员，他们需要理解用户的目标和他们将怎样使用系统达到他们的目标。

在您维护安全类型和避免集成电路般函数时,你可以使用C++的强大的力量进行消息传递。

Anthony是Just Software Solution有限公司的一位软件开发者和执行管理者。可以通过anthony@justsoftwaresolutions.co.uk与之联系。

使用通用的消息传递方式传递数据在C++程序中很普遍。这种技术经常用于在线程间以及从/到GUI组件间传递数据。但是消息传递仍然很难实现得良好，这是因为在常见的消息传递方式中，暴露出了过多的藕合、缺少类型安全和集成电路般的消息处理函数。

在本文中，我提出了一种技术，这种技术利用C++的强大力量来避免上述缺陷——在消息传递中避免不适当的藕合，维护类型安全，以及消除集成电路般的消息处理函。( The only translation units that need to known the details of a message are those containning the source and handler functions for that specific message type.) 需要转换的单元，即需要知道的消息详细内容是包含了特定消息的类型的源代码和处理函数。

传统技术

大概应用得最为广泛的消息传递技术是使用一个带有特殊成员来表示消息类型的结构体，该消息类型是消息的标识。这种方式被广泛应用归咎于使用了基于C的API，比如X11和Microsoft Windows。在这种方法中，消息结构体中要么有一个通用的字体用于区别不同消息的意义，这个字段可被所有消息重用，或者它是更大结构的第一个成员，它的类型由类型代码来确定。Windows API使用前面的技术，而X11使用后面的方法。无论用哪种方式，处理消息的代码都须检查类型编码，用以决定怎么处理该消息。

这些技术的问题是:缺乏类型安全，集成电路般的处理函数，需要管理类型编码来确保消息唯一性的适当层次。特别的，缺乏类型安全意味着使用之前，使用代码必须把消息数据转换成适当的类型。这一步是极易出错的，尤其在当复制和粘贴代码时(这种非常的手段常发生在为处理相似消息编写代码的时候)，编译器不会在这种错误给出任何警告。

缺乏类型安全还有一个额外的问题——即它不可能简单有效的通过消息系统传递资源或变长的数据， 这是因为消息的发送方总是不能知道何时（或是否）该消息已被处理过了。

在这部分，集成电路般的消息处理函数是必须用于确定消息类型的产物，通过已接收的消息来消息类型，然后得到如何处理它的方式。这种处理函数往往实现为一个很大的switch语句或是一串if eles if。一些框架，如MFC，提供一些宏来减弱这种问题的影响，它这不能完全消除这个问题。

最后的问题是管理类型代码。它必须要求接收消息代码清楚地知道是哪一个消息，以便于正确的处理它。所以，类型代码需要在处理它的相关代码中确保唯一性。比如，在Windows API中，指定范围的消息类型在不同的应用程序中代表不同的意义，并且，在同一个应就用程序中，其它范围的消息类型在不同窗口或GUI组件中代表不同的意义。 通常,需要所有类型代码的列表，该列表要求在给定的范围中保持唯一，以便于检查它们的唯一性。列表常常是以头文件的形式给出，头文件中定义了类型代码，包含在需要知道消息类型的所有地方。这种方式容易导致应用程序不同部分之间的藕合,而这些部分之间却没有任何关系。由于这种过度的藕，简单的变更导致过多的重新编译。

面向对象技术

对象技术的一个常见特征是所有相关消息类派生自一个通用的基类。该特征用编译器能认识的真实类型代替了显式的类型代码。不仅如此，它还有了一个重要的，超越C风格技术的优点——类型安全。它提供的通用基类的析构函数是虚函数，所以派生的消息类能自由地管理资源，如变长的数据，这些数据可以在析构函数中释放。仅有的需求是接受消息的代码能正确地销毁消息对象，无论它们是否被处理。

管理类型代码现在被替换为管理类。这是一个更加简单的任务，由于可能的消息名字的范围是没有限制的，可能存在名字冲突，但这一点可以通过名字空间来解决。

保持简单

最简单的OOP技术就是用dynamic_cast检查实际的消息类型代替检查消息编码。然而，这依然面临着集成电路般地消息处理方式——现在通过包括dynamic_cast的比较链也优于通过类型编码字段比较链。如列表1:

void  handleMessage(Message *  message)
{
     if (Message1 *  m = dynamic_cast < Message1 *> (message))
     {
        handleMessage1(m);
    }
     else   if (Message2 *  m = dynamic_cast < Message2 *> (message))
     {
        handleMessage2(m);
    }
     //  
}

[列表1]

一般而言，由于仅仅是消息的源代码和接受消息的源代码需求知道相关的消息，所以依赖得到降低。然后，集成电路般地处理函数现在需要知道消息的有关细节，所以dynamic_cast需要消息的完整定义——如果分派给另外的函数处理实际的消息，C风格技术的处理函数不需求知道消息的细节。

双重分派

(Direct testing of a class's type using dynamic_cast is generally indicative of a design problem;)类的类型用dynamic_cast的直测试一般可表示为设计问题;然而，简单地把虚函数放在消息类中起不到任何作用——它将把消息处理与消息缠绕在一起，这个消息使在第一个地方发送消息的目的失败。

双重分派的关键点是，在消息类中的虚函数带有一个作为参数的处理器，然后在处理器上把自已作为参数传递传递给另一个函数并完成调用。因为这里的第二次到处理器的回调已经在实际的派生类中完成，所以真实的消息类型已经知道，在处理器上能调用适当的函数，无论这个函数是通过重载的方式实现还是另外独立命名的函数来实现(列表2)。

[列表2]

依赖于重载的方式来区别不同的消息有利于大多数平衡——现在在每个消息类中虚函数的实现方式是相同的，如果需要，可以通过宏来一致地包装，或通过从一个消息到另一个消息中直接复制，不会有出错的机会。

双重分派存在一个缺点——高度藕合。由于通过重载方式在处理器类中的选择处理函数，在消息类中虚函数的实现需要知道处理器类的定义的全部，因此必须注意到在系统中每个其它的类的名字。不光这些，如果要支持不同的处理器类，处理函数必须在通用的处理器的基类中声明为虚函数，所以每个处理器类必须在系统中注意到所有的消息类型(列表3)。增加或删除一个消息类型会引起应用程序大部分代码重新编译。

class  MessageHandler
{
     virtual   void  process(Message1 * ) = 0 ;
     virtual   void  process(Message2 * ) = 0 ;
     virtual   void  process(Message3 * ) = 0 ;
     virtual   void  process(Message4 * ) = 0 ;
     //  overloads of process for other messages
} ;
class  SpecificMessageHandler:
     public  MessageHandler
{
     void  process(Message1 * );
     void  process(Message2 * );
     void  process(Message3 * );
     void  process(Message4 * );
     //  overloads of process for other messages
} ;
class  OtherSpecificMessageHandler:
     public  MessageHandler
{
     void  process(Message1 * );
     void  process(Message2 * );
     void  process(Message3 * );
     void  process(Message4 * );
     //  overloads of process for other messages
} ;

[列表3]

动态双重分派

（It was against this backdrop that I developed the technique I call "Dynamic Double Dispatch."）我开发了一种技术，我称其为“动态双重分派”，这种技术用于解决上述问题。尽管有基本的双重分派技术，但选择的消息处理函数使用的是在编译阶段确定的重载技术(尽管发现在正确的消息处理器类中的实现是使用虚函数机制),而动态双重分派是在运行时检查在处理器上适当的处理函数的。结论是动态双重分派消除了双重分派的依赖问题。消息类型不在需要注意到其它的消息类型，并且处理器类仅需要注意到它的它要处理的消息。

动态检查的关键点是：每一个消息类型有一个独立的基类——处理器类从适当的，设计为处理消息的基类派生。然后在每个消息类中的分派函数能用dynamic_cast来检查从正派基类派生的处理器类，因而实现了正确的处理函数。(列表4)

class  MessageHandlerBase
{};
class  Message1HandlerBase:
     public   virtual  MessageHandlerBase
{
     virtual   void  process(Message1 * ) = 0 ;
};
class  Message1
{
     void  dispatch(MessageHandlerBase *  handler)
    {
        dynamic_cast < Message1HandlerBase &> ( * handler).process( this );
    }
};
class  Message2HandlerBase:
     public   virtual  MessageHandlerBase
{
     virtual   void  process(Message2 * ) = 0 ;
};
class  Message2:
     public  MessageBase
{
     void  dispatch(MessageHandlerBase *  handler)
    {
        dynamic_cast < Message2HandlerBase &> ( * handler).process( this );
    }
};
//  
class  SpecificMessageHandler:
     public  Message1HandlerBase,
     public  Message2HandlerBase
{
     void  process(Message1 * );
     void  process(Message2 * );
};
class  OtherSpecificMessageHandler:
     public  Message3HandlerBase,
     public  Message4HandlerBase
{
     void  process(Message3 * );
     void  process(Message4 * );
};

[列表4]

(Of course, having a completely separate handler base class for each message type would add excessive complication, as the dispatch function for each message type would now be specific to that message type, and the base classes would have to be written separately, despite being fundamentally the same, except for the message type they referenced.)
诚然，为每个消息类型分别编写的处理器基类将增加过多的复杂性，同样地，每个消息类型各自的分派函数现在需要特别指定，基类也需求分别编写,然后除了它们引用的消息类型外基础是相同的。消除这种重复的关键是使基类成为模板，用消息类型作为模板参数——分派函数引用到模板的实现好于指定类型；请看列表5。

[列表5]
出于简化原因，在消息类中的分派函数几乎相同，但也不是完全相同——它们必须明确的指定属于它们的指定消息类，以便于转换为适当的处理器基类。像软件中许多事情一样，这个问题可以增加一个额外的层来解决——分派函数可以委托给单个模板函数，这个模板函数使用模板参数类型来确定消息类型和把处理器转换到适当的类型上。(列表6)

[列表6]

通过进一步抽象在消息对象中分派函数的不同之处,我们把工作集中到一个地方——模板函数的定义；它提供了为修改行为的单一点。在消息类中剩下的分派函数都是相同的，这足以把它们简化到隐藏细节的宏中或在消息类之间中逐字复制。

未处理的消息

迄今为止，我们展示的 dynamicDispach模板函数的代码假定处理的类是从适当的SpecificMessageHandler是派生的；如是不是这样， dynamic_cast将抛出std::bad_cast异常。有时这就足够了，但是有的时候，有更适当的行为——也许更好的做法是抛弃消息，这不能被接受消息的代理处理或调用catch-all处理器。举例来说，dynamicDispatch 函数能被调整，用基于指针的转换代替基于引用的转换，所以结果值可以与NULL进行测试。

缺点(Trade-Off)在哪里？
有如此多的优点，一定存在它的缺点，那它的缺点在哪里呢？在这里，有两个缺点。第一个是：额外的动态转换，两个虚函数调用会影响性能。如果性能上是一个问题，这就是一个疑问，但是，在很多情况下，花销在这里的额外的时间是不值得关注的。可以使用相应的工具来签定到底哪里才是真正的性能瓶颈所在。

第二个缺点是:需要为每个消息处理从指定的基类派生消息处理器。因为处理新的消息类型需要修改两个地方——适当的基类列表入口和处理函数，所以这可能成为错误的来源，遗失处理函数容易被发现，因为这是全局点，但是遗失基类在代码运行时只产生不易查觉的缺陷。因为没有处理函数的时候仅仅是不调用它。这些错误在单元测试的时候是很容易被抓出来的，所以所实话，这些不便之处都成不了大问题。

From: Brian Sun @ 爬树的泡泡[http://www.blogjava.net/briansun]

{关键字}

测试驱动开发/Test Driven Development/TDD
测试用例/TestCase/TC
设计/Design
重构/Refactoring

{TDD的目标}

Clean Code That Works

这句话的含义是，事实上我们只做两件事情：让代码奏效（Work）和让代码洁净（Clean），前者是把事情做对，后者是把事情做好。想想看，其实我们平时所做的所有工作，除去无用的工作和错误的工作以外，真正正确的工作，并且是真正有意义的工作，其实也就只有两大类：增加功能和提升设计，而TDD 正是在这个原则上产生的。如果您的工作并非我们想象的这样，（这意味着您还存在第三类正确有意义的工作，或者您所要做的根本和我们在说的是两回事），那么这告诉我们您并不需要TDD，或者不适用TDD。而如果我们偶然猜对（这对于我来说是偶然，而对于Kent Beck和Martin Fowler这样的大师来说则是辛勤工作的成果），那么恭喜您，TDD有可能成为您显著提升工作效率的一件法宝。请不要将信将疑，若即若离，因为任何一项新的技术——只要是从根本上改变人的行为方式的技术——就必然使得相信它的人越来越相信，不信的人越来越不信。这就好比学游泳，唯一能学会游泳的途径就是亲自下去游，除此之外别无他法。这也好比成功学，即使把卡耐基或希尔博士的书倒背如流也不能拥有积极的心态，可当你以积极的心态去成就了一番事业之后，你就再也离不开它了。相信我，TDD也是这样！想试用TDD的人们，请遵循下面的步骤：

编写TestCase	-->	实现TestCase	-->	重构
（确定范围和目标）		（增加功能）		（提升设计）

[友情提示：敏捷建模中的一个相当重要的实践被称为：Prove it With Code，这种想法和TDD不谋而合。]

{TDD的优点}

『充满吸引力的优点』

1. 完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
2. 全面正确的认识代码和利用代码，而传统的方式没有这个机会。
3. 为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。
4. 开发小组间降低了交流成本，提高了相互信赖程度。
5. 避免了过渡设计。
6. 系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
7. TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。

   『不显而易见的优点』

8. 逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。
9. 大部分时间代码处在高质量状态，100％的时间里成果是可见的。
10. 由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。
11. 为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
12. 在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。

    『有争议的优点』

13. 事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，这很正常，世界总是这样。
14. 发现比传统测试方式更多的Bug。
15. 使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。
16. 总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子）
17. 单元测试非常有趣。

编写TestCase	-->	实现TestCase	-->	重构
（不可运行）		（可运行）		（重构）

{FAQ}

[什么时候重构？]
如果您在软件公司工作，就意味着您成天都会和想通过重构改善代码质量的想法打交道，不仅您如此，您的大部分同事也都如此。可是，究竟什么时候该重构，什么情况下应该重构呢？我相信您和您的同事可能有很多不同的看法，最常见的答案是“该重构时重构”，“写不下去的时候重构”，和“下一次迭代开始之前重构”，或者干脆就是“最近没时间，就不重构了，下次有时间的时候重构吧”。正如您已经预见到我想说的——这些想法都是对重构的误解。重构不是一种构建软件的工具，不是一种设计软件的模式，也不是一个软件开发过程中的环节，正确理解重构的人应该把重构看成一种书写代码的方式，或习惯，重构时时刻刻有可能发生。在TDD中，除去编写测试用例和实现测试用例之外的所有工作都是重构，所以，没有重构任何设计都不能实现。至于什么时候重构嘛，还要分开看，有三句话是我的经验：实现测试用例时重构代码，完成某个特性时重构设计，产品的重构完成后还要记得重构一下测试用例哦。

[什么时候设计？]
这个问题比前面一个要难回答的多，实话实说，本人在依照TDD开发软件的时候也常常被这个问题困扰，总是觉得有些问题应该在写测试用例之前定下来，而有些问题应该在新增一个一个测试用例的过程中自然出现，水到渠成。所以，我的建议是，设计的时机应该由开发者自己把握，不要受到TDD方式的限制，但是，不需要事先确定的事一定不能事先确定，免得捆住了自己的手脚。

[什么时候增加新的TestCase？]
没事做的时候。通常我们认为，如果你要增加一个新的功能，那么先写一个不能通过的 TestCase；如果你发现了一个bug，那么先写一个不能通过的TestCase；如果你现在什么都没有，从0开始，请先写一个不能通过的 TestCase。所有的工作都是从一个TestCase开始。此外，还要注意的是，一些大师要求我们每次只允许有一个TestCase亮红灯，在这个 TestCase没有Green之前不可以写别的TestCase，这种要求可以适当考虑，但即使有多个TestCase亮红灯也不要紧，并未违反TDD 的主要精神。

[TestCase该怎么写？]
测试用例的编写实际上就是两个过程：使用尚不存在的代码和定义这些代码的执行结果。所以一个 TestCase也就应该包括两个部分——场景和断言。第一次写TestCase的人会有很大的不适应的感觉，因为你之前所写的所有东西都是在解决问题，现在要你提出问题确实不大习惯，不过不用担心，你正在做正确的事情，而这个世界上最难的事情也不在于如何解决问题，而在于ask the right question！

[TDD能帮助我消除Bug吗？]
答：不能！千万不要把“测试”和“除虫”混为一谈！“除虫”是指程序员通过自己的努力来减少bug的数量（消除bug这样的字眼我们还是不要讲为好^_^），而“测试”是指程序员书写产品以外的一段代码来确保产品能有效工作。虽然TDD所编写的测试用例在一定程度上为寻找bug提供了依据，但事实上，按照TDD的方式进行的软件开发是不可能通过TDD再找到bug的（想想我们前面说的“完工时完工”），你想啊，当我们的代码完成的时候，所有的测试用例都亮了绿灯，这时隐藏在代码中的bug一个都不会露出马脚来。

但是，如果要问“测试”和“除虫”之间有什么联系，我相信还是有很多话可以讲的，比如TDD事实上减少了bug的数量，把查找bug战役的关注点从全线战场提升到代码战场以上。还有，bug的最可怕之处不在于隐藏之深，而在于满天遍野。如果你发现了一个用户很不容易才能发现的bug，那么不一定对工作做出了什么杰出贡献，但是如果你发现一段代码中，bug的密度或离散程度过高，那么恭喜你，你应该抛弃并重写这段代码了。TDD避免了这种情况，所以将寻找bug的工作降低到了一个新的低度。

[我该为一个Feature编写TestCase还是为一个类编写TestCase？]
初学者常问的问题。虽然我们从TDD 的说明书上看到应该为一个特性编写相应的TestCase，但为什么著名的TDD大师所写的TestCase都是和类/方法一一对应的呢？为了解释这个问题，我和我的同事们都做了很多试验，最后我们得到了一个结论，虽然我不知道是否正确，但是如果您没有答案，可以姑且相信我们。

我们的研究结果表明，通常在一个特性的开发开始时，我们针对特性编写测试用例，如果您发现这个特性无法用TestCase表达，那么请将这个特性细分，直至您可以为手上的特性写出TestCase为止。从这里开始是最安全的，它不会导致任何设计上重大的失误。但是，随着您不断的重构代码，不断的重构 TestCase，不断的依据TDD的思想做下去，最后当产品伴随测试用例集一起发布的时候，您就会不经意的发现经过重构以后的测试用例很可能是和产品中的类/方法一一对应的。

[什么时候应该将全部测试都运行一遍？]
Good Question！大师们要求我们每次重构之后都要完整的运行一遍测试用例。这个要求可以理解，因为重构很可能会改变整个代码的结构或设计，从而导致不可预见的后果，但是如果我正在开发的是一个ERP怎么办？运行一遍完整的测试用例可能将花费数个小时，况且现在很多重构都是由工具做到的，这个要求的可行性和前提条件都有所动摇。所以我认为原则上你可以挑几个你觉得可能受到本次重构影响的TestCase去run，但是如果运行整个测试包只要花费数秒的时间，那么不介意你按大师的要求去做。

[什么时候改进一个TestCase？]
增加的测试用例或重构以后的代码导致了原来的TestCase的失去了效果，变得无意义，甚至可能导致错误的结果，这时是改进TestCase的最好时机。但是有时你会发现，这样做仅仅导致了原来的TestCase在设计上是臃肿的，或者是冗余的，这都不要紧，只要它没有失效，你仍然不用去改进它。记住，TestCase不是你的产品，它不要好看，也不要怎么太科学，甚至没有性能要求，它只要能完成它的使命就可以了——这也证明了我们后面所说的“用Ctrl-C/Ctrl-V编写测试用例”的可行性。

但是，美国人的想法其实跟我们还是不太一样，拿托尼巴赞的MindMap来说吧，其实画MindMap只是为了表现自己的思路，或记忆某些重要的事情，但托尼却建议大家把MindMap画成一件艺术品，甚至还有很多艺术家把自己画的抽象派MindMap拿出来帮助托尼做宣传。同样，大师们也要求我们把TestCase写的跟代码一样质量精良，可我想说的是，现在国内有几个公司能把产品的代码写的精良？？还是一步一步慢慢来吧。

[为什么原来通过的测试用例现在不能通过了？]
这是一个警报，Red Alert！它可能表达了两层意思——都不是什么好意思——1）你刚刚进行的重构可能失败了，或存在一些错误未被发现，至少重构的结果和原来的代码不等价了。2）你刚刚增加的TestCase所表达的意思跟前面已经有的TestCase相冲突，也就是说，新增的功能违背了已有的设计，这种情况大部分可能是之前的设计错了。但无论哪错了，无论是那层意思，想找到这个问题的根源都比TDD的正常工作要难。

[我怎么知道那里该有一个方法还是该有一个类？]
这个问题也是常常出现在我的脑海中，无论你是第一次接触TDD或者已经成为 TDD专家，这个问题都会缠绕着你不放。不过问题的答案可以参考前面的“什么时候设计”一节，答案不是唯一的。其实多数时候你不必考虑未来，今天只做今天的事，只要有重构工具，从方法到类和从类到方法都很容易。

[我要写一个TestCase，可是不知道从哪里开始？]
从最重要的事开始，what matters most？从脚下开始，从手头上的工作开始，从眼前的事开始。从一个没有UI的核心特性开始，从算法开始，或者从最有可能耽误时间的模块开始，从一个最严重的bug开始。这是TDD主义者和鼠目寸光者的一个共同点，不同点是前者早已成竹在胸。

[为什么我的测试总是看起来有点愚蠢？]
哦？是吗？来，握个手，我的也是！不必担心这一点，事实上，大师们给的例子也相当愚蠢，比如一个极端的例子是要写一个两个int变量相加的方法，大师先断言2+3=5，再断言5+5=10，难道这些代码不是很愚蠢吗？其实这只是一个极端的例子，当你初次接触TDD时，写这样的代码没什么不好，以后当你熟练时就会发现这样写没必要了，要记住，谦虚是通往TDD的必经之路！从经典开发方法转向TDD就像从面向过程转向面向对象一样困难，你可能什么都懂，但你写出来的类没有一个纯OO的！我的同事还告诉我真正的太极拳，其速度是很快的，不比任何一个快拳要慢，但是初学者（通常是指学习太极拳的前10年）太不容易把每个姿势都做对，所以只能慢慢来。

[什么场合不适用TDD？]
问的好，确实有很多场合不适合使用TDD。比如对软件质量要求极高的军事或科研产品——神州六号，人命关天的软件——医疗设备，等等，再比如设计很重要必须提前做好的软件，这些都不适合TDD，但是不适合TDD不代表不能写TestCase，只是作用不同，地位不同罢了。

{Best Practise}

[微笑面对编译错误]
学生时代最害怕的就是编译错误，编译错误可能会被老师视为上课不认真听课的证据，或者同学间相互嘲笑的砝码。甚至离开学校很多年的老程序员依然害怕它就像害怕迟到一样，潜意识里似乎编译错误极有可能和工资挂钩（或者和智商挂钩，反正都不是什么好事）。其实，只要提交到版本管理的代码没有编译错误就可以了，不要担心自己手上的代码的编译错误，通常，编译错误都集中在下面三个方面：
（1）你的代码存在低级错误
（2）由于某些Interface的实现尚不存在，所以被测试代码无法编译
（3）由于某些代码尚不存在，所以测试代码无法编译
请注意第二点与第三点完全不同，前者表明设计已存在，而实现不存在导致的编译错误；后者则指仅有TestCase而其它什么都没有的情况，设计和实现都不存在，没有Interface也没有Implementation。

另外，编译器还有一个优点，那就是以最敏捷的身手告诉你，你的代码中有那些错误。当然如果你拥有Eclipse这样可以及时提示编译错误的IDE，就不需要这样的功能了。

[重视你的计划清单]
在非TDD的情况下，尤其是传统的瀑布模型的情况下，程序员不会不知道该做什么，事实上，总是有设计或者别的什么制品在引导程序员开发。但是在TDD的情况下，这种优势没有了，所以一个计划清单对你来说十分重要，因为你必须自己发现该做什么。不同性格的人对于这一点会有不同的反应，我相信平时做事没什么计划要依靠别人安排的人（所谓将才）可能略有不适应，不过不要紧，Tasks和Calendar（又称效率手册）早已成为现代上班族的必备工具了；而平时工作生活就很有计划性的人，比如我:)，就会更喜欢这种自己可以掌控Plan的方式了。

[废黜每日代码质量检查]
如果我没有记错的话，PSP对于个人代码检查的要求是蛮严格的，而同样是在针对个人的问题上， TDD却建议你废黜每日代码质量检查，别起疑心，因为你总是在做TestCase要求你做的事情，并且总是有办法（自动的）检查代码有没有做到这些事情 ——红灯停绿灯行，所以每日代码检查的时间可能被节省，对于一个严格的PSP实践者来说，这个成本还是很可观的！

此外，对于每日代码质量检查的另一个好处，就是帮助你认识自己的代码，全面的从宏观、微观、各个角度审视自己的成果，现在，当你依照TDD做事时，这个优点也不需要了，还记得前面说的TDD的第二个优点吗，因为你已经全面的使用了一遍你的代码，这完全可以达到目的。

但是，问题往往也并不那么简单，现在有没有人能告诉我，我如何全面审视我所写的测试用例呢？别忘了，它们也是以代码的形式存在的哦。呵呵，但愿这个问题没有把你吓到，因为我相信到目前为止，它还不是瓶颈问题，况且在编写产品代码的时候你还是会自主的发现很多测试代码上的没考虑到的地方，可以就此修改一下。道理就是如此，世界上没有任何方法能代替你思考的过程，所以也没有任何方法能阻止你犯错误，TDD仅能让你更容易发现这些错误而已。

[如果无法完成一个大的测试，就从最小的开始]
如果我无法开始怎么办，教科书上有个很好的例子：我要写一个电影列表的类，我不知道如何下手，如何写测试用例，不要紧，首先想象静态的结果，如果我的电影列表刚刚建立呢，那么它应该是空的，OK，就写这个断言吧，断言一个刚刚初始化的电影列表是空的。这不是愚蠢，这是细节，奥运会五项全能的金牌得主玛丽莲·金是这样说的：“成功人士的共同点在于……如果目标不够清晰，他们会首先做通往成功道路上的每一个细小步骤……”。

[尝试编写自己的xUnit]
Kent Beck建议大家每当接触一个新的语言或开发平台的时候，就自己写这个语言或平台的xUnit，其实几乎所有常用的语言和平台都已经有了自己的 xUnit，而且都是大同小异，但是为什么大师给出了这样的建议呢。其实Kent Beck的意思是说通过这样的方式你可以很快的了解这个语言或平台的特性，而且xUnit确实很简单，只要知道原理很快就能写出来。这对于那些喜欢自己写底层代码的人，或者喜欢控制力的人而言是个好消息。

[善于使用Ctrl-C/Ctrl-V来编写TestCase]
不必担心TestCase会有代码冗余的问题，让它冗余好了。

[永远都是功能First，改进可以稍后进行]
上面这个标题还可以改成另外一句话：避免过渡设计！

[淘汰陈旧的用例]
舍不得孩子套不着狼。不要可惜陈旧的用例，因为它们可能从概念上已经是错误的了，或仅仅会得出错误的结果，或者在某次重构之后失去了意义。当然也不一定非要删除它们，从TestSuite中除去（JUnit）或加上Ignored（NUnit）标签也是一个好办法。

[用TestCase做试验]
如果你在开始某个特性或产品的开发之前对某个领域不太熟悉或一无所知，或者对自己在该领域里的能力一无所知，那么你一定会选择做试验，在有单元测试作工具的情况下，建议你用TestCase做试验，这看起来就像你在写一个验证功能是否实现的 TestCase一样，而事实上也一样，只不过你所验证的不是代码本身，而是这些代码所依赖的环境。

[TestCase之间应该尽量独立]
保证单独运行一个TestCase是有意义的。

[不仅测试必须要通过的代码，还要测试必须不能通过的代码]
这是一个小技巧，也是不同于设计思路的东西。像越界的值或者乱码，或者类型不符的变量，这些输入都可能会导致某个异常的抛出，或者导致一个标示“illegal parameters”的返回值，这两种情况你都应该测试。当然我们无法枚举所有错误的输入或外部环境，这就像我们无法枚举所有正确的输入和外部环境一样，只要TestCase能说明问题就可以了。

[编写代码的第一步，是在TestCase中用Ctrl-C]
这是一个高级技巧，呃，是的，我是这个意思，我不是说这个技巧难以掌握，而是说这个技巧当且仅当你已经是一个TDD高手时，你才能体会到它的魅力。多次使用TDD的人都有这样的体会，既然我的TestCase已经写的很好了，很能说明问题，为什么我的代码不能从TestCase拷贝一些东西来呢。当然，这要求你的TestCase已经具有很好的表达能力，比如断言f (5)=125的方式显然没有断言f(5)=5^(5-2)表达更多的内容。

[测试用例包应该尽量设计成可以自动运行的]
如果产品是需要交付源代码的，那我们应该允许用户对代码进行修改或扩充后在自己的环境下run整个测试用例包。既然通常情况下的产品是可以自动运行的，那为什么同样作为交付用户的制品，测试用例包就不是自动运行的呢？即使产品不需要交付源代码，测试用例包也应该设计成可以自动运行的，这为测试部门或下一版本的开发人员提供了极大的便利。

[只亮一盏红灯]
大师的建议，前面已经提到了，仅仅是建议。

[用TestCase描述你发现的bug]
如果你在另一个部门的同事使用了你的代码，并且，他发现了一个bug，你猜他会怎么做？他会立即走到你的工位边上，大声斥责说：“你有bug！”吗？如果他胆敢这样对你，对不起，你一定要冷静下来，不要当面回骂他，相反你可以微微一笑，然后心平气和的对他说：“哦，是吗？那么好吧，给我一个TestCase证明一下。”现在局势已经倒向你这一边了，如果他还没有准备好回答你这致命的一击，我猜他会感到非常羞愧，并在内心责怪自己太莽撞。事实上，如果他的TestCase没有过多的要求你的代码（而是按你们事前的契约），并且亮了红灯，那么就可以确定是你的bug，反之，对方则无理了。用TestCase描述bug的另一个好处是，不会因为以后的修改而再次暴露这个bug，它已经成为你发布每一个版本之前所必须检查的内容了。

{关于单元测试}

单元测试的目标是

Keep the bar green to keep the code clean

这句话的含义是，事实上我们只做两件事情：让代码奏效（Keep the bar green）和让代码洁净（Keep the code clean），前者是把事情做对，后者是把事情做好，两者既是TDD中的两顶帽子，又是xUnit架构中的因果关系。

单元测试作为软件测试的一个类别，并非是xUnit架构创造的，而是很早就有了。但是xUnit架构使得单元测试变得直接、简单、高效和规范，这也是单元测试最近几年飞速发展成为衡量一个开发工具和环境的主要指标之一的原因。正如Martin Fowler所说：“软件工程有史以来从没有如此众多的人大大收益于如此简单的代码！”而且多数语言和平台的xUnit架构都是大同小异，有的仅是语言不同，其中最有代表性的是JUnit和NUnit，后者是前者的创新和扩展。一个单元测试框架xUnit应该：1）使每个TestCase独立运行；2）使每个TestCase可以独立检测和报告错误；3）易于在每次运行之前选择TestCase。下面是我枚举出的xUnit框架的概念，这些概念构成了当前业界单元测试理论和工具的核心：

[测试方法/TestMethod]
测试的最小单位，直接表示为代码。

[测试用例/TestCase]
由多个测试方法组成，是一个完整的对象，是很多TestRunner执行的最小单位。

[测试容器/TestSuite]
由多个测试用例构成，意在把相同含义的测试用例手动安排在一起，TestSuite可以呈树状结构因而便于管理。在实现时，TestSuite形式上往往也是一个TestCase或TestFixture。

[断言/Assertion]
断言一般有三类，分别是比较断言（如assertEquals），条件断言（如isTrue），和断言工具（如fail）。

[测试设备/TestFixture]
为每个测试用例安排一个SetUp方法和一个TearDown方法，前者用于在执行该测试用例或该用例中的每个测试方法前调用以初始化某些内容，后者在执行该测试用例或该用例中的每个方法之后调用，通常用来消除测试对系统所做的修改。

[期望异常/Expected Exception]
期望该测试方法抛出某种指定的异常，作为一个“断言”内容，同时也防止因为合情合理的异常而意外的终止了测试过程。

[种类/Category]
为测试用例分类，实际使用时一般有TestSuite就不再使用Category，有Category就不再使用TestSuite。

[忽略/Ignored]
设定该测试用例或测试方法被忽略，也就是不执行的意思。有些被抛弃的TestCase不愿删除，可以定为Ignored。

[测试执行器/TestRunner]
执行测试的工具，表示以何种方式执行测试，别误会，这可不是在代码中规定的，完全是与测试内容无关的行为。比如文本方式，AWT方式，swing方式，或者Eclipse的一个视图等等。

{实例：Fibonacci数列}

下面的Sample展示TDDer是如何编写一个旨在产生Fibonacci数列的方法。
（1）首先写一个TC，断言fib(1) = 1;fib(2) = 1;这表示该数列的第一个元素和第二个元素都是1。

（2）上面这段代码不能编译通过，Great！——是的，我是说Great！当然，如果你正在用的是Eclipse那你不需要编译，Eclipse 会告诉你不存在fib方法，单击mark会问你要不要新建一个fib方法，Oh，当然！为了让上面那个TC能通过，我们这样写：

（3）现在那个TC亮了绿灯，wow！应该庆祝一下了。接下来要增加TC的难度了，测第三个元素。

不过这样写还不太好看，不如这样写：

（4）新增加的断言导致了红灯，为了扭转这一局势我们这样修改fib方法，其中部分代码是从上面的代码中Ctrl-C/Ctrl-V来的：

（5）天哪，这真是个贱人写的代码！是啊，不是吗？因为TC就是产品的蓝本，产品只要恰好满足TC就ok。所以事情发展到这个地步不是fib方法的错，而是TC的错，于是TC还要进一步要求：

（6）上有政策下有对策。

（7）好了，不玩了。现在已经不是贱不贱的问题了，现在的问题是代码出现了冗余，所以我们要做的是——重构：

（8）好，现在你已经fib方法已经写完了吗？错了，一个危险的错误，你忘了错误的输入了。我们令0表示Fibonacci中没有这一项。

then change the method fib to make the bar grean：

（9）下班前最后一件事情，把TC也重构一下：

（10）打完收工。

{关于本文的写作}

在本文的写作过程中，作者也用到了TDD的思维，事实上作者先构思要写一篇什么样的文章，然后写出这篇文章应该满足的几个要求，包括功能的要求（要写些什么）和性能的要求（可读性如何）和质量的要求（文字的要求），这些要求起初是一个也达不到的（因为正文还一个字没有），在这种情况下作者的文章无法编译通过，为了达到这些要求，作者不停的写啊写啊，终于在花尽了两个月的心血之后完成了当初既定的所有要求（make the bar green），随后作者整理了一下文章的结构（重构），在满意的提交给了Blog系统之后，作者穿上了一件绿色的汗衫，趴在地上，学了两声青蛙叫。。。。。。。^_^

{后记：Martin Fowler在中国}

从本文正式完成到发表的几个小时里，我偶然读到了Martin Fowler先生北京访谈录，其间提到了很多对测试驱动开发的看法，摘抄在此：

Martin Fowler：当然（值得花一半的时间来写单元测试）！因为单元测试能够使你更快的完成工作。无数次的实践已经证明这一点。你的时间越是紧张，就越要写单元测试，它看上去慢，但实际上能够帮助你更快、更舒服地达到目的。
Martin Fowler：什么叫重要？什么叫不重要？这是需要逐渐认识的，不是想当然的。我为绝大多数的模块写单元测试，是有点烦人，但是当你意识到这工作的价值时，你会欣然的。
Martin Fowler：对全世界的程序员我都是那么几条建议：……第二，学习测试驱动开发，这种新的方法会改变你对于软件开发的看法。……

——《程序员》，2005年7月刊

{鸣谢}

fhawk
Dennis Chen
般若菩提
Kent Beck
Martin Fowler
c2.com

阅读笔记：积极主动，充满热情，是这封信的核心。最近自己也经历了一些事情，在面临未来发展前景的分岔道路，需要做出选择时，明知道某一条具有更大的发展前景，但是却由于未知的待遇问题放弃了选择它，并非不积极主动，不充满热情，但是某些时候有很多的外在因素可以影响决定。

李开复《给中国学生的第五封信》，继续传授关于积极行动、把握自己命运的人生经验，这是“一封有关积极主动的信”。

    “今天大多数优秀的企业对人才的期望是：积极主动、充满热情、灵活自信的人”，学会“自己的事，自己负责，自己解决”，“我不能，别的任何人也不能代替你走过那条路；你必须自己去走。”

一个人被击败，不是因为外界环境的阻碍，而是取决于他对环境如何反应。“有勇气改变可以改变的事情，有胸怀接受不可改变的事情，有智慧来分辨两者的不同。”

    “如果你想知道什么，就自己到网上去找，不要急着去问别人；如果你听到了什么，不要盲目信从，应当自己主动去网上求证。”

    被动就是弃权，不做决定也是一种决定。下定决心，每一件小事都要表达出自己的意见，就算你不是很在乎。例如，自己决定在餐馆点什么菜，自己决定自己的衣着打扮，周末时自己决定要去哪里玩，等等。设法让自己潜意识里的“我感觉，我想要”体现出来，不要被动，不要从众，避免盲目听从父母、老师、名人……

    积极主动的人总是在言语中赋予自己决定的权利，他们喜欢说的话包括：“试试看有没有其他的可能性。”“也许我可以换个思路。”“我可以控制自己的情绪。”“我可以想出更有效的表达方式。”“我的感觉是……”“我选择……”“我要……”“我情愿……”“我打算……”“我决定……”等等。积极主动地抓住命运中你可以选择、可以改变、可以最大化你的影响力的部分。

    美国人很喜欢尝试不同的工作，他们一生中平均要换四次工作。经常给自己设立一些极具挑战性、但绝非遥不可及的目标。

    “等待的方法有两种，一种是什么事也不做地空等，另一种是一边等，一边把事情向前推动。”在机遇还没有来临时，就应事事用心，事事尽力。一旦机遇到来，一定要全力以赴，把握机遇。

    在公司里，经常得到晋升机会的人，大多是能够积极推销和表达自己的、有进取心的人。当他们还是公司的一名普通员工时，只要和公司利益或者团队利益相关的事情，他们就会不遗余力地发表自己的见解、贡献自己的主张，帮助公司制定和安排工作计划；在完成本职工作后，他们总能协助其他人尽快完成工作；他们常常鼓励自己和同伴，提高整个队伍的士气；这些人总是以事为本、以事为先——他们都是最积极主动的人。

    在人生的旅途中，你是你自己惟一的司机，千万不要让别人驾驶你的生命之车。你要稳稳地坐在司机的位置上，决定自己何时要停、要倒车、要转弯、要加速、要刹车等等。只有积极主动的人才能在瞬息万变的竞争环境中赢得成功，只有善于展示自己的人才能在工作中获得真正的机会。

    “你们的时间有限，所以不要浪费时间在别人的生活里。不要被信条所惑 – 盲从信条是活在别人的生活里。不要让任何人的意见淹没了你内在的心声。重要的，拥有跟随内心和直觉的勇气。你的内心与直觉知道你真正想成为什么样的人。任何其他事物都是次要的。”——斯蒂夫 乔布斯 （苹果公司总裁）于2005年斯坦福大学毕业典礼。

#pragma once
#include  < iostream >
using   namespace  std;
class  Base
{
public :
  Base( void );
   ~ Base( void );
public :
   virtual   void  print(ostream &  output)  =   0 ;
  friend ostream &   operator   << (ostream &  output,Base &  obj);
private :
   char *  name_;
   int  age_;
} ;

#include "StdAfx.h"
#include ".\base.h"

Base::Base(void)
{
  name_ = "This is data1";
  age_ = 18;
}

Base::~Base(void)
{
}

void Base::print(ostream& output)
{
  output<<"name = " <<name_<<endl;
  output<<"age = "<<age_<<endl;
}

ostream& operator<<(ostream& output,Base& obj)
{
  obj.print(output);
  return output;
}

#pragma once
#include "Base.h"
class Derived :public Base
{
public:
  Derived(int score = 80);
  ~Derived(void);
  virtual void print(ostream& output);
private:
  int score_;
};

#include "StdAfx.h"
#include ".\derived.h"

Derived::Derived(int score):score_(score)
{
  
}

Derived::~Derived(void)
{
}

void Derived::print(ostream& output)
{
  Base::print(output);
  output<<"score = "<<score_<<endl;
}

// Test_VirtualFirendFunction.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <iostream>
#include "Derived.h"
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
  Derived  d;

  Derived  d2(90);
  cout<<d<<endl<<d2<<endl;
    return 0;
}

name = This is data1
age = 18
score = 80

name = This is data1
age = 18
score = 90

结果：
任何从Base派生类的，都可以利用cout<<obj的机制通过流进行输出。

同样道理，也可以利用此方法实现ACE_InputCDR  / ACE_OutputCDR对网络操作序列化操作。
(本文也是回答某网友关于派生类不能重载的问题的回复)