日期:2011-03-22 16:17:00 来源:本站整理
<b>操纵final的注意事项</b>[Java编程]
本文“<b>操纵final的注意事项</b>[Java编程]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
计划一个类时,常常需求考虑能否将一个办法设为final.大概会认为利用自己的类时履行效率非常重要,没有人想覆盖自己的办法.这种设法在某些时刻是精确的.
但要慎重作出自己的假定.普通,我们很难猜测一个类今后会以什么样的情势再生或反复操纵.通例用处的类特别如此.若将一个办法定义成final,便大概根绝了在其他程序员的项目中对自己的类举行担当的途径,因为我们根本没有想到它会象那样利用.
尺度Java库是阐述这一概念的最好例子.此中分外常用的一个类是Vector.假如我们考虑代码的履行效率,就会发现只有不把任何办法设为final,才能使其施展更大的作用.我们很简单就会想到自己应担当和覆盖如此有效的一个类,但它的计划者却否定了我们的设法.但我们至少可以用两个来由来辩驳他们.首先,Stack(仓库)是从Vector担当来的,亦即Stack“是”一个Vector,这种说法是不切当的.其次,关于Vector很多重要的办法,如addElement()以及elementAt()等,它们都变成了synchronized(同步的).正如在第14章要讲到的那样,这会造成明显的性能开销,大概会把final供应的性能改进抵销得一干二净.因此,程序员不得不猜想到底应当在那边举行优化.在尺度库里竟然采取了如此拙笨的计划,真不敢想象会在程序员里引发什么样的情感.
另一个值得注意的是Hashtable(散列表),它是另一个重要的尺度类.该类没有采取任何final办法.正如我们在本书其他地方提到的那样,明显一些类的计划人员与其他计划人员有着全然差别的本质(注意对比Hashtable极短的办法名与Vecor的办法名).对类库的用户来说,这明显是不该该如此简单就可以看出的.一个产品的计划变得不一致后,会加大用户的工作量.这也从另一个侧面夸大了代码计划与查抄时需求很强的责任心.
以上是“<b>操纵final的注意事项</b>[Java编程]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |
评论内容只代表网友观点,与本站立场无关!
评论摘要(共 0 条,得分 0 分,平均 0 分)
查看完整评论