Use final considerations

When designing a class, you often need to consider whether to set a method to final. You may find it important to perform efficiently with your own classes, and no one wants to overwrite their own methods. The idea is right at some point.

But be careful to make your own assumptions. Often, it is difficult to predict what form a class will regenerate or reuse in the future. This is especially true for general purpose classes. If you define a method final, you may end up inheriting from your own classes in other programmers ' projects, because we never thought it would work like that.

The standard Java library is the best example to illustrate this view. One of the most commonly used classes is vector. If we consider the execution efficiency of the code, we will find that only if we do not set any method final, we can make it play a greater role. It is easy to think that we should inherit and cover such a useful class, but its designers deny our ideas. But we can at least use two reasons to refute them. First of all, stack (stack) is inherited from Vector, that is, stack "is" a vector, this argument is not accurate. Secondly, many important methods for vectors, such as addelement () and ElementAt (), have become synchronized (synchronized). As in the 14th chapter, this can result in significant performance overhead and may bring out the final performance improvements. As a result, programmers have to guess exactly where to optimize. In the standard library, incredibly clumsy design, I can not imagine what kind of emotion will be triggered in the programmer.

Another notable is the Hashtable (hash table), which is another important standard class. The class does not use any final method. As we mentioned elsewhere in this book, it is clear that some class designers have a completely different quality with other designers (note that the Hashtable method name and the Vecor method name are relatively short). For the users of the class library, this is obviously not so easy to see. When a product's design becomes inconsistent, it increases the user's workload. This also emphasizes the need for a strong sense of responsibility in code design and inspection from another side.