|
| |
 精品推荐 |
 |
|
| |
|
|
|
|
你的代码真的很健壮吗
|
日期：2007年5月16日 作者： 查看:[大字体
中字体 小字体]
|
考虑第二种情况，调用者通过其他函数得到了一个index，然后他想取得这个index下的CItem指针，但是他不想多写两行代码去判断这个index的合法性，他想：“如果这个index是合法的就请返回给我这个index下的CItem指针，如果不合法就返回一个NULL好了“。这样做只要一行代码就够了，他省下了一行代码，也许不止一行，因为在很多地方都需要呼叫GetItem()这个函数，所以，他省下了许多行代码。他会这样使用GetItem()：
void SomeFunc( int nIndex )
{
CItem* pItem = im.GetItem( nIndex );
if( pItem ){
//do something.
}
}
void SomeFunc( int nIndex )
{
CItem* pItem = im.GetItem( nIndex );
if( pItem ){
//do something.
}
}
如果CItemManager的实现者和使用者是同一个程序员，我们经常会写出像上面的代码，毕竟可以省下一行代码，而且上面的代码看去还不错，简洁明了。但是仔细推敲一下， 我们发现，按照以上的要求实现的GetItem()是一个不良的设计。
首先，它违反了单一职责原则（SRP）。按照以上的要求实现的GetItem()其实完成了两项功能：第一项功能用来判断index是否合法；第二项功能用来取得指定index下的CItem指针。GetItem()只应该负责取得指定index下的CItem指针，检查index的合法性应该交给其他的函数。这里，调用者可以通过GetItemCount()来判断index的合法性。
其次，函数的返回值具有二义性。如果函数返回NULL，那么这个NULL可以代表index不合法，也可以解释为，指定的index下的值就是NULL，因为从编译器的角度NULL也是一个CItem指针。这里GetItem()混合了两种功能的返回值，而且第一项功能的返回值使用了第二项功能的返回值中的一个特例。这样的设计破坏了程序的完整性。假如CItemManager不是管理CItem指针，而是管理CItem对象，你就不会那样设计GetItem()函数了。
如果真的想在GetItem()里实现index的合法性检查，那么GetItem()的定义应该改成这样：
bool GetItem( int index, CItem* & pItem );
如果index不合法，函数返回false；如果index合法，函数返回true，并且pItem返回该index下的CItem指针。经过这么一改，返回值的二义性被消除了，但是你是否觉得，GetItem()的语义已经有点变味了，这更像是在实现FindItem了。然而，按照index去Find一个Item似乎又不合理，我们进入了一个两难的境地。
退一步海阔天空。在GetItem()里检查index的合法性，并不会让我们的程序更健壮。一个比较好的做法是，由调用者负责index的合法性检查。
所以 SomeFunc应该改成这样：
void SomeFunc( int nIndex )
{
if( nIndex >= im.GetItemCount( ) )
return;
CItem* pItem = im.GetItem( nIndex );
pItem->…;
}
void SomeFunc( int nIndex )
{
if( nIndex >= im.GetItemCount( ) )
return;
CItem* pItem = im.GetItem( nIndex );
pItem->…;
}
而GetItem()的实现应该改成这样：
CItem* CItemManager::GetItem( int nIndex )
{
ASSERT( nIndex >= 0 && nIndex < m_nCount );
…
return pItem;
}
以上的实现我们使用了ASSERT()来检查参数的合法性，当参数不合法时，程序会被终止。ASSERT()断言只有在调试版才有效，所以程序不能依赖它来做错误处理。ASSERT()在这里的作用是，一方面在调试程序的时候，能够帮助我们尽早的发现错误。错误越早被发现，越容易被解决；另一方面，按照Robert Martin在Agile Software Development一书中所述，软件具有三项职责，最后一项便是：和阅读它的人沟通1。这些断言代码可以向阅读代码的人传递这样的信息，当程序运行到这里的时候，必须满足这些条件。
我是否在鼓励不要写防御性代码？
读到这里，你也许觉得我在鼓励不要在函数里检查参数的合法性，不要写防御性代码。是这样吗？答案显然是否定的。我要强调的是不要盲目的加入防御性代码，这样做并不能增强系统的健壮性。当要加入防御性代码的时候，你需要
分析一下，这个条件是应该假设的，还是应该防御的。对于应该假设的条件，可以使用ASSERT()断言来检查，对于应该防御的条件，必须用专门的代码来处理。
那么如何判断一个条件是应该假设的，还是应该防御的呢？这让我想起了荣耀先生(optimizer)的两篇沉思录，《你防御了吗？》2和《别人的棺材》3。
《你防御了吗？》说的是作者写的一个用于显示SQL语句的程序，作者假设输入的SQL语句不会超过4000个字符，结果有一天的确有人输入了超过4000个字符的SQL语句，然后程序崩溃了。这引起了作者对防御性编程的思考。
上一篇:软件架构训练基础教程之Intenet技术
下一篇:64位计算中的Java虚拟机(JVM)性能测试
|
| 你的代码真的很健壮吗 相关文章： |
|
|
|
| 你的代码真的很健壮吗 相关软件： |
|
|
|
|
