设计一个类时，往往需要思量是否将一个要领设为final。大概会以为利用本身的类时执行效率很是重要，没有人想包围本身的要领。这种想法在某些时候是正确的。
但要慎重作出本身的假定。凡是，我们很难预测一个类今后会以什么样的形式再生或反复操作。通例用途的类尤其如此。若将一个要领界说成final，就大概杜绝了在其他措施员的项目中对本身的类举办担任的途径，因为我们基础没有想到它会象那样利用。
尺度Java库是叙述这一概念的最好例子。个中出格常用的一个类是Vector。假如我们思量代码的执行效率，就会发明只有不把任何要领设为final，才气使其发挥更大的浸染。我们很容易就会想到本身应担任和包围如此有用的一个类，但它的设计者却否认了我们的想法。但我们至少可以用两个来由来辩驳他们。首先，Stack（仓库）是从Vector担任来的，亦即Stack“是”一个Vector，这种说法是不确切的。其次，对付Vector很多重要的要领，如addElement()以及elementAt()等，它们都酿成了synchronized（同步的）。正如在第14章要讲到的那样，这会造成显著的机能开销，大概会把final提供的机能改进抵销得一干二净。因此，措施员不得不揣摩到底应该在那边举办优化。在尺度库里居然回收了如此鸠拙的设计，真不敢想象会在措施员里激发什么样的情绪。
另一个值得留意的是Hashtable（散列表），它是另一个重要的尺度类。该类没有回收任何final要领。正如我们在本书其他处所提到的那样，显然一些类的设计人员与其他设计人员有着全然差异的素质（留意较量Hashtable极短的要领名与Vecor的要领名）。对类库的用户来说，这显然是不该该如此等闲就能看出的。一个产物的设计变得纷歧致后，会加大用户的事情量。这也从另一个侧面强调了代码设计与查抄时需要很强的责任心。
