C++批评系列：继承的本质

　2008-03-08 21:54:54　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾剧懓顪冪€ｎ亜顒㈡い鎰Г閹便劌顫滈崱妤€骞婄紓鍌氬€瑰銊╁箟缁嬫鍚嬮柛顐線缂冩洟姊婚崒娆戭槮婵犫偓闁秵鎯為幖娣妼缁愭鏌″搴′簽濞戞挸绉甸妵鍕冀椤愵澀娌梺缁樻尪閸庣敻寮婚敐澶婂嵆闁绘劖绁撮崑鎾诲捶椤撴稑浜炬慨妯煎亾鐎氾拷

闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾剧懓顪冪€ｎ亝鎹ｉ柣顓炴閵嗘帒顫濋敐鍛婵°倗濮烽崑娑⑺囬悽绋挎瀬闁瑰墽绮崑鎰版煙缂佹ê绗ч柍褜鍓﹂崣鍐潖閸濆嫅褔宕惰娴犲ジ姊虹拠鑼闁煎綊绠栭幃楣冩倻閽樺鎽曢梺闈涱檧婵″洭宕㈤悽鍛娾拺閻熸瑥瀚烽崯蹇涙煕閻樺磭澧甸柕鍡楀€圭缓浠嬪川婵犲嫬骞堥梺纭呭閹活亞妲愰弴鐔哄ⅰ闂傚倷绶氬ḿ褍煤閵堝洠鍋撳顐㈠祮闁绘侗鍣ｉ獮鎺懳旈埀顒傜不閿濆棛绡€闂傚牊绋戦弳娆徝瑰⿰鍫㈢暫闁哄矉缍佹慨鈧柍鎯版硾濠€杈ㄧ珶閺囩喓绡€婵﹩鍘鹃崢鐢告⒑缂佹ê濮﹂柛鎾村哺閹ɑ娼忛妸銈囩畾闂佸湱绮敮鐐存櫠濞戞氨纾肩紓浣贯缚濞插鈧娲栧畷顒冪亙闂佸憡鍔曢崯鐘诲礈濠靛牊宕叉繛鎴炨缚閺嗗棗鈹戦悩杈厡闁轰焦鐗滅槐鎾存媴娴犲鎽甸梺鍦嚀濞层倝鎮鹃悜钘夌闁规惌鍘介崓鐢告⒑閻熸澘鎮侀柣鎺炵畵閹骞栨担鍏夋嫽婵炶揪绲块崕銈夊吹閳ь剟姊洪幖鐐测偓鏍偋閻樿崵宓侀煫鍥ㄧ⊕閺呮悂鏌ㄩ悤鍌涘

濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴ｆ閺嬩線鏌涘☉姗堟敾闁告瑥绻戦妵鍕箻閸楃偟浠肩紓浣哄閸ㄥ爼寮诲☉銏犵疀闂傚牊绋掗悘鍫ユ倵閻熺増鍟炵紒璇插暣婵＄敻宕熼姘鳖啋闁诲酣娼ч幗婊堟偩婵傚憡鈷戠痪顓炴媼濞兼劖绻涢懠顒€鏋庢い顐㈢箳缁辨帒螣閼测晜鍤岄梻渚€鈧偛鑻晶顔肩暆閿濆牆鍔垫い锔界叀閹繝濡舵径瀣帾闂佸壊鍋呯换鍐磻椤忓懐绠剧€瑰壊鍠曠花濠氬箚閻斿吋鈷戦悗鍦У閵嗗啴鏌ら崘鑼煟鐎规洘绻堥弫鍐焵椤掑嫧鈧棃宕橀鍢壯囨煕閳╁喚娈橀柣鐔稿姍濮婃椽鎮℃惔鈩冩瘣闂佺粯鐗曢妶绋跨暦閻戞ḿ绡€闁搞儜鍐ㄧギ闂備線娼ф蹇曟閺囥垹鍌ㄦい蹇撶墛閳锋垿鏌熼懖鈺佷粶闁告梹顨婇弻锟犲川椤旈敮濮囩紓浣稿€圭敮鐔妓囩€靛摜纾奸弶鍫涘妼缁楁碍绻涢悡搴ｇ闁糕斁鍓濋幏鍛存煥鐎ｅ灚缍楅梻鍌氬€峰ù鍥ь浖閵娾晜鍊块柨鏇炲€哥粻鏌ユ煕閵夘喖澧柡瀣╃窔閺岀喖宕滆鐢盯鏌￠崨顔藉€愰柡灞诲姂閹倝宕掑☉姗嗕紦闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾剧懓顪冪€ｎ亜顒㈡い鎰Г閹便劌顫滈崱妤€骞婄紓鍌氬€瑰銊╁箟缁嬫鍚嬮柛顐線缂冩洟姊婚崒娆戭槮婵犫偓闁秵鎯為幖娣妼缁愭鏌″搴′簽濞戞挸绉甸妵鍕冀椤愵澀娌梺缁樻尪閸庣敻寮婚敐澶婂嵆闁绘劖绁撮崑鎾诲捶椤撴稑浜炬慨妯煎亾鐎氾拷　　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌ｉ幋锝呅撻柛銈呭閺屻倝宕妷锔芥瘎婵炲濮靛銊ф閹捐纾兼繛鍡樺笒閸橈紕绱撴笟鍥ф珮闁搞劌鐖兼俊鎾礃椤旂厧绐涢梺鍝勵槹閸ㄥ綊宕㈠ú顏呭€垫鐐茬仢閸旀碍銇勯敂璇茬仸鐎规洩绻濋獮搴ㄦ嚍閵壯冨妇闂傚⿴鍋勫ú锕€煤閺嶃劎澧￠梻鍌欐祰椤曆呪偓鍨浮瀹曟粓鎮㈡總澶嬬稁闂佹儳绻愬﹢杈╁閸忛棿绻嗘い鏍ㄧ閹牊銇勯銏㈢劯婵﹨娅ｉ幏鐘绘嚑椤掑偆鍞规繝娈垮枟鑿ч柛鏃€鍨垮畷娲焵椤掍降浜滈柟鍝勭Ф椤︼箓鏌涢妶搴″⒋闁哄本鐩獮妯兼崉閻戞ḿ鈧顪冮妶搴′簻缂佺粯鍔楅崣鍛渻閵堝懐绠伴悗姘煎墴閹顢橀悜鍡樺瘜闂侀潧鐗嗗Λ娆戠矆閳ь剟姊洪悷鏉挎毐闂佸府绲介悾宄扳堪閸曨偒鍤ら柣搴㈢⊕鑿ら柟閿嬫そ濮婄粯绗熼崶褌绨介梺绋款儐閻╊垶骞婇悢纰辨晬婵炴垶鐟﹂悵宄邦渻閵堝棙鐓ュ褏鏅竟鏇㈡偂鎼搭喚鍞甸柣鐘烘鐏忋劑宕濋悢铏圭＜濠㈣泛瀛╅鐘绘煃瑜滈崜姘额敊閺嶎厼绐楅柡宥庡幐閳ь剨绠撻弻銊р偓锝傛櫇缁犳艾鈹戦鐣岀畵闁活厼鐗嗗嵄闁绘垼濮ら埛鎴犵磼鐎ｎ偒鍎ラ柛搴㈠姍閺岀喖鎮烽悧鍫熸倷闁捐崵鍋ら弻娑㈠箛閳轰礁唯濠碘剝褰冮悧濠勬崲濞戙垹骞㈡俊銈呭暟椤斿鈹戦悙鑼闁挎洏鍨归～蹇曠磼濡顎撴俊鐐差儏缁ㄨ偐鎲伴崱娆戠＝闁稿本姘ㄨⅵ闂佺ǹ顑嗛幐鑽ゆ崲濞戞埃鍋撳☉娆嬬細闁活厹鍊濋弻娑㈠箻鐠虹儤鐏堥悗瑙勬礃濡炰粙宕洪埀顒併亜閹哄秹妾峰ù婊勭矒閺岀喖鎮滃Ο铏逛淮闂侀€炲苯澧紓宥咃工椤曪綁骞庣粵瀣櫌闂佸憡娲﹂崜娑㈠储闁秵鐓熼幖鎼灣缁夐潧霉濠婂懎鍘撮柣鎿冨墴椤㈡宕掑Δ鈧禍楣冩偡濞嗗繐顏痪鎯ь煼閺屾稑螖閳ь剟宕崸妤婃晪闁挎繂顦壕褰掓煟閺囨氨鍔嶉棄瀣⒒閸屾瑧顦﹂柟纰卞亜铻為悗闈涙憸娑撳秹鏌熼幑鎰靛殭闁藉啰鍠栭弻鏇熺箾閻愵剚鐝曢梺绋款儏濡繈寮诲☉姘勃闁告挆鈧Σ鍫濐渻閵堝懘鐛滈柟鍑ゆ嫹

核心提示：Eiffel和C++都提供了多继续的机制，但java却没有，C++批评系列：继承的本质，因为它认为多继续会导致许多问题的出现，不过Java提供了接口(interface)作为一种替换机制，我们也可以把这个称为不好的程序设计风格， C++和Eiffel的另一个不同之处在于直接的重复继续，它类似于Objective C中的

　　Eiffel和C++都提供了多继续的机制。但java却没有，因为它认为多继续会导致许多问题的出现。不过Java提供了接口(interface)作为一种替换机制，它类似于Objective C中的协议(PRotocol)。Sun宣称接口可以提供多继续所能提供的所有特性。　　Sun所宣称的“多继续会带来许多的问题”这个观点是对的，尤其是在C++中用以实现多继续的方法更能说明这一点。那些看起来似乎使用多继续会比单继续更简单的理由，现在都以被证实是毫无意义。例如，如何制订对于从两个类之上继续得到的具有相同名字的数据项之间的策略？它们之间是否兼容？假如是的话，那他们是否应该被合并成为一个实体？假如不兼容，那应该如何区分它们？……这样的列表可以列出很长很长。　　Java的接口机制也可以用以实现多继续，但它也有一个很重要的不同之处（与C++相比）：继续中的接口必须是抽象的。由于使用接口并没有任何的实作，这就消除了需要从不同实作之间选择的可能。Java答应在接口中声明具有常数字段。当需要多继续时，他们就合并成为一个实体，这样也就不会导致歧义的产生。但是，当这些常数具有不同的值时，又有什么会发生呢？　　由于Java不支持多继续，我们就不可以像在C++和Eiffel中那样使用混合(mixin)了。混合是一种特性，它可以把从不同的类中得到的不同的非抽象的函数放到一起形成一个新的复杂的类。例如，我们可能希望从不同的源代码中导入一些utility函数。然而，我们也可以通过使用组合而不是继续来达到同样的效果，因此，这也就不会对Java构成一个重要的攻击了。　　Eiffel在解决多继续问题时并没有导入一个单独的接口机制。　　有些人可能认为，相对于多继续来说，单继续更优雅一些。这是一个很非凡的观点。　　BETA [Madsen 93]就属于认为“多继续不优雅”的那一种：“Beta中没有多继续，这主要是因为（对于多继续）缺乏一个深刻的理论上的理解，并且当前的（对于多继续的）建议在技术上看来也非常复杂”。他们引用了Flavors（一种可以将类混合在一起的语言）为证据。与Madsen相比，Flavors中的多继续与其顺序有关，也就是说，继续自(A,B)和继续自(B,A)是不一样的。　　Ada95是另一种不支持多继续的语言。Ada95支持单继续，并把它叫做标记类型扩展（tagged type extension）。　　另外一些人认为，对于某些非凡模型下的问题，多继续可以提供优雅的解法，因此为之付出的努力也是值得的。虽然上面所列出的关于多继续的问题列表并不完善，它仍然显示：与多继续相关的问题是可以被系统地辨识出来的，而一旦问题被确认，它们也就可以被优雅地解决。当[Sakkinen 92]对于多继续研究到达一个很深的程度后，它就得出了上述定义。　　Eiffel中采用的方法是，多继续会引发一些有趣的且有挑战性的问题，然后再优雅地解决它们。程序员所需做的所有决定都被限制在类的继续子句中。它包括使用renaming来保证众多从继续中得来的同名特性最终成为具有不同名字的特性，对于继续而来的特性所施展的新的eXPort策略：redefining和undefining，以及用来消除歧义的select。在所有的情况下，编译器都会为我们做好这一切，为了使得语义清楚而不管是选择使用fork或是join，程序员都具有完全的控制权。　　C++中相对Eiffel来说有着另外一种不同的用于消除歧义的机制。在Eiffel中，在renames子句中，特性间必须有着不同的名字。在C++中，可以使用域解析操作符’::’来区分成员。Eiffel的做法好处在于，歧义在声明中就被消除掉了。Eiffel的继续子句相对C++的来说要复杂不少，但它的代码也显得更简单，更稳固，并更具弹性。这也就是声明方法与操作符方法相比的好处所在。在C++中，每次当我们碰到在多个成员间具有歧义时，我们必须在代码中使用域解析操作符。这经使得代码变得混乱不堪，影响其延展性，假如有其他地方的改变会影响歧义时，我们可能就需要在歧义可能出现的每个地方改变已有的代码。　　依照[Stroustrup 94]中12.8节所说，ANSI委员会考虑过使用renaming，但是这个提议被委员会中的一个成员所阻塞掉了，他坚持让委员会中的其他成员用两周时间来好好地考虑这个问题。在12.8节中给出的例子显示了在没有显示的renaming的前提下，如何做可以得到同样的效果。问题在于，假如这都需要那些专家们使用两周来考虑如何实现，那留给我们的空间又有多少呢？　　域解析操作符并不只是被用来消除多继续所带来的歧义。由于设计良好的语言可以避免歧义的出现，因此域解析操作符也就是一个丑陋的，加深复杂性的实作手法。　　在C++中，“如何来声明多继续中的父类们”是一个很复杂的问题。它影响到了建构函数被调用的次序，当程序员确实想从子类转到父类时也会导致问题的出现。然而，我们也可以把这个称为不好的程序设计风格。　　C++和Eiffel的另一个不同之处在于直接的重复继续，Eiffel中答应：　class B inherit A, A end 　　但　　class B : public A, public A { }; 　　却不被C++认可。