### [final 忠告](https://lingcoder.gitee.io/onjava8/#/book/08-Reuse?id=final-%e5%bf%a0%e5%91%8a) 在設計類時將一個方法指明為 final 看上去是明智的。你可能會覺得沒人會覆寫那個方法。有時這是對的。 但請留意你的假設。通常來說，預見一個類如何被復用是很困難的，特別是通用類。如果將一個方法指定為**final**，可能會防止其他程序員的項目中通過繼承來復用你的類，而這僅僅是因為你沒有想到它被以那種方式使用。 Java 標準類庫就是一個很好的例子。尤其是 Java 1.0/1.1 的**Vector**類被廣泛地使用，而且從效率考慮（這近乎是個幻想），如果它的所有方法沒有被指定為**final**，可能會更加有用。很容易想到，你可能會繼承并覆寫這么一個基礎類，但是設計者們認為這么做不合適。有兩個諷刺的原因。第一，**Stack**繼承自**Vector**，就是說**Stack**是個**Vector**，但從邏輯上來說不對。盡管如此，Java 設計者們仍然這么做，在用這種方式創建**Stack**時，他們應該意識到了**final**方法過于約束。 第二，**Vector**中的很多重要方法，比如`addElement()`和`elementAt()`方法都是同步的。在“并發編程”一章中會看同步會導致很大的執行開銷，可能會抹煞**final**帶來的好處。這加強了程序員永遠無法正確猜到優化應該發生在何處的觀點。如此笨拙的設計卻出現在每個人都要使用的標準庫中，太糟糕了。慶幸的是，現代 Java 容器用**ArrayList**代替了**Vector**，它的行為要合理得多。不幸的是，仍然有很多新代碼使用舊的集合類庫，其中就包括**Vector**。 Java 1.0/1.1 標準類庫中另一個重要的類是**Hashtable**（后來被**HashMap**取代），它不含任何**final**方法。本書中其他地方也提到，很明顯不同的類是由不同的人設計的。**Hashtable**就比**Vector**中的方法名簡潔得多，這又是一條證據。對于類庫的使用者來說，這是一個本不應該如此草率的事情。這種不規則的情況造成用戶需要做更多的工作——這是對粗糙的設計和代碼的又一諷刺。