final的注意事項

設(shè)計一個類時，往往需要考慮是否將一個方法設(shè)為final。可能會覺得使用自己的類時執(zhí)行效率非常重要，
沒有人想覆蓋自己的方法。這種想法在某些時候是正確的。
但要慎重作出自己的假定。通常，我們很難預(yù)測一個類以后會以什么樣的形式再生或重復(fù)利用。常規(guī)用途的

類尤其如此。若將一個方法定義成final，就可能杜絕了在其他程序員的項目中對自己的類進行繼承的途
徑，因為我們根本沒有想到它會象那樣使用。
標(biāo)準(zhǔn)Java 庫是闡述這一觀點的最好例子。其中特別常用的一個類是Vector。如果我們考慮代碼的執(zhí)行效
率，就會發(fā)現(xiàn)只有不把任何方法設(shè)為final，才能使其發(fā)揮更大的作用。我們很容易就會想到自己應(yīng)繼承和
覆蓋如此有用的一個類，但它的設(shè)計者卻否定了我們的想法。但我們至少可以用兩個理由來反駁他們。首
先，Stack（堆棧）是從Vector 繼承來的，亦即Stack“是”一個Vector，這種說法是不確切的。其次，對
于Vector 許多重要的方法，如addElement()以及elementAt()等，它們都變成了synchronized（同步
的）。正如在第14 章要講到的那樣，這會造成顯著的性能開銷，可能會把final 提供的性能改善抵銷得一干電腦常識www.boydavid.com 
二凈。因此，程序員不得不猜測到底應(yīng)該在哪里進行優(yōu)化。在標(biāo)準(zhǔn)庫里居然采用了如此笨拙的設(shè)計，真不敢
想象會在程序員里引發(fā)什么樣的情緒。
另一個值得注意的是Hashtable（散列表），它是另一個重要的標(biāo)準(zhǔn)類。該類沒有采用任何final 方法。正
如我們在本書其他地方提到的那樣，顯然一些類的設(shè)計人員與其他設(shè)計人員有著全然不同的素質(zhì)（注意比較
Hashtable 極短的方法名與Vecor 的方法名）。對類庫的用戶來說，這顯然是不應(yīng)該如此輕易就能看出的。
一個產(chǎn)品的設(shè)計變得不一致后，會加大用戶的工作量。這也從另一個側(cè)面強調(diào)了代碼設(shè)計與檢查時需要很強
的責(zé)任心

服務(wù)器租用/服務(wù)器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]