第5章-糖果机界面.docVIP

第5章 糖果机界面 Microsoft雇员从公司得到的一个好处是可以随便享用免费的软饮料，如香味塞尔查矿泉水、牛奶加巧克力和软包装果汁等，管够。但讨厌的是，如果你想吃糖果，就得自己掏腰包。所以有时馋了，我就溜到自动售货机那儿。一次，我塞进几个25美分的硬币，然后按下选择键4和5。但当售货机吐出茉莉香味的泡泡糖，而不是我想买的老奶奶牌花生黄油饼干时我愣住了。自然，售货机没错，是我错了，45号是代表泡泡糖。看一眼售货机上花生黄油饼干的小标记，进一步证实了我的错误。标记上写着花生黄油饼干，21号，45美分。 这件事一直使我耿耿于怀，因为假如自动售货机的设计者多花30秒钟考虑一下他们的设计，就不会使我以及无数其他人遇到这种事情：买了不想买的东西。如果他们想过：“嗯，人们在向键盘塞钱时常常会想着45美分 ─── 我敢打赌，人们在向键盘塞钱时常常会把价钱错当选择号输入给售货机。因此，我们应该选用字母键，不应该使用数字键，以避免这种情况。 这样设计自动售货机并不会增加他的造价，也不会明显改变它的原有设计，但每当在键盘上敲入45美分时就会发现机器拒绝接受这种输入，提醒你敲入相应的字母代码。这种设计会引导人们去做正确的事情。 当我们设计函数的界面时，所面临的是相同的问题。不幸的是，程序员不常考虑其他程序员会怎样使用他所设计的函数。就像上面的糖果机界面一样，设计上的细微差别有可能非常容易引起错误，也可能非常容易避免错误。光使设计出的函数没有错误并不够，还必须使它们使用起来很安全。 很自然，getchar()会得到一个int 标准的C库函数以及按照该模式编写的数以千计的其它函数，都有着上述糖果机式界面，容易使用户犯错误。就说getchar函数吧，我们有充足的理由说这个函数的界面是有风险的，其中最严重的问题是该函数的设计名鼓励程序员编写有错的代码。关于这一点，还是让我们看看Brian Kernighan和Dennis Ritchie在其“C 程序设计语言”一书中是怎么说的吧： 考虑以下的代码： char c; c = getchar(); if( c == EOF ) …… 在不进行符号扩展的机器上，c总是正数因为它是char类型而EOF却是负数，结果上面的测试条件总会失败。为了避免这一点，必须用int而不用char来保存getchar返回值的变量。 这不是说明即使有经验的程序员也必须小心谨慎地使用函数吗？按照getchar这样的函数名，将c定义成字符类型是很自然的事情，这就是程序员会遇到这个错误的原因。但getchar非得如此有害不可吗？该函数要做的工作并不复杂，不过是从某个设备上读入一个字符并返回可能的错误情况。 以下代码给出了另一个常见的问题： /* strdup ─── 为一个字符串建立副本 */ char* strdup( char* str ) { char* strNew; strNew = (char*)malloc( strlen(str)+1 ); strcpy( strNew, str ); return( strNew ); } 这个函数在一般的情况下都会工作得很好，除非内存空间耗尽引起了malloc的失败。这时，它返回一个不指向任何内存单元的NULL指针。但当目的指针strNew为NULL时，鬼才知道strcpy会做些什么。strcpy不论是失败，还是悄悄地冲掉内存中的信息都不是程序员所期望的。 程序员之所以在使用getchar和malloc时会遇到麻烦，是因为他们能够写出即使有缺陷但表面上仍能工作的代码。直到几个星期甚至几个月后，才会碰到一连串不易发生的事件而导致这些代码的失败，就像泰坦尼克号邮船沉没的灾难一样。getchar和malloc都不能引导程序员写出正确的代码，都极易使程序员忽视错误情况。 getchar和malloc的问题在于他们返回的值不精确。有时他们返回所要的有效数据，但另一些时候他们却返回不可思议的错误值。 假如getchar不返回奇怪的EOF值，把c声明为字符类型就是正确的，程序员也就不会遇到Kernighan和Ritchie所说的错误。同样，假如malloc不返回好象是内存指针的NULL，程序员就不会忘记对相应的错误进行处理。问题在于不怕这些函数返回错误，而怕他们把错误隐藏在程序员极易忽视的正常返回值中。 如果我们重新设计getchar，使他们分别返回两个不同输出怎么样？它可以根据是否成功读入一个新的字符而返回TRUE或FALSE，并把读入的字符返回到一个通过引用传递给他的变量中： flag fGetChar(char* pch); 通过这一界面我们可以很自然地写出 chat ch; if( fGetChar( ch ) ) ch中是下一个字符 else 碰到了EOF，ch中是无用信息 这样一来，“