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