设计一个类时，往往需要考虑是否将一个方法设为final。可能会觉得使用自己的类时执行效率非常重要，没有人想覆盖自己的方法。这种想法在某些时候是正确的。
但要慎重作出自己的假定。通常，我们很难猜测一个类以后会以什么样的形式再生或重复利用。常规用途的类尤其如此。若将一个方法定义成final，就可能杜绝了在其他程序员的项目中对自己的类进行继续的途径，因为我们根本没有想到它会象那样使用。
标准Java库是阐述这一观点的最好例子。其中非凡常用的一个类是Vector。假如我们考虑代码的执行效率，就会发现只有不把任何方法设为final，才能使其发挥更大的作用。我们很轻易就会想到自己应继续和覆盖如此有用的一个类，但它的设计者却否定了我们的想法。但我们至少可以用两个理由来反驳他们。首先，Stack（堆栈）是从Vector继续来的，亦即Stack“是”一个Vector，这种说法是不确切的。其次，对于Vector许多重要的方法，如addElement()以及elementAt()等，它们都变成了synchronized（同步的）。正如在第14章要讲到的那样，这会造成显著的性能开销，可能会把final提供的性能改善抵销得一干二净。因此，程序员不得不猜测到底应该在哪里进行优化。在标准库里居然采用了如此笨拙的设计，真不敢想象会在程序员里引发什么样的情绪。
另一个值得注重的是Hashtable（散列表），它是另一个重要的标准类。该类没有采用任何final方法。正如我们在本书其他地方提到的那样，显然一些类的设计人员与其他设计人员有着全然不同的素质（注重比较Hashtable极短的方法名与Vecor的方法名）。对类库的用户来说，这显然是不应该如此轻易就能看出的。一个产品的设计变得不一致后，会加大用户的工作量。这也从另一个侧面强调了代码设计与检查时需要很强的责任心。
