Comments on: final – just say no?

By: R.J.

R.J. — Tue, 15 Jun 2004 19:25:21 +0000

I definitely agree that over-use of the final keyword can cause problems. However, that’s a product of bad design decisions, not the feature itself. The same could be said for use of the public keyword to continue that thread.

The reason I brought up data encapsulation (and really, this wasn’t the best choice of words because encapsulation implies protecting data from OUTSIDE influences, and an inherited member is not truly outside…) is because all too often the situations which elicit the use of the final keyword are situations where an algorithm must perform a certain way for preconditions and postconditions to be ensured safely (often in conjunction with the template method pattern, or something of the sort). I can certainly see a possibility where a method being overriden that was never intended to be swapped out could cause data corruption, therefore producing similar effects to an API that can produce corrupt data.

I don’t see the final keyword as being the issue; more-so bad uses of the keyword.

Also, I’ve always found it to be a tenuous line to walk when balancing ease of testing and confidence of design. It seems like often times the two conflict (primarily because testing requires some degree of visibility to data).

By: Sam Newman

Sam Newman — Mon, 14 Jun 2004 19:58:27 +0000

This is certainly not an argument against data encapsulation – in fact I find it hard to see how Data Encapsulation can be helped by final (if you don’t want data/methods accessed via a subclass or proxy, then make them private!). API formality is a concept I admit I know little about, unless you are talking about creation of well defined API’s – again I don’t see how final applies to this, except in a situation where you are using it to enforce an API invariants.

Some would argue that everything _should_ be public – I would not go as far, however you are being incredibly restrictive if you don’t use final carefully. The fact that String is final has never been a problem – however my problems with NakedClass being final have been made worse by virtue of the problems associated with creating instances of this class.

By: R.J.

R.J. — Mon, 14 Jun 2004 19:41:40 +0000

This almost sounds vaguely like an argument against encapsulation and API formality. Although using final is, indeed, a way to restrict the behavior of an individual who is extending your component, I don’t see how that is any different really that restricting an individual who is using your component (as, for example, composition is very similar to inheritance).
Inheritance is just another tool in the OO developers toolbag, and final is just another way to ensure that behavior from point a to point b is correct. All things considered, Can’t the same be said for private variables, constructor initialized arguments, and whatever else? Why use anything but ‘public’ for that matter? I personally rarely use the ‘final’ keyword in regards to anything but variables; there aren’t a lot of cases in the software I develop where it is completely relevant. However, I do recognize its value in ensuring the correctness of operation in context to a framework.

In some ways it can be said that the essense of most of the architectual concepts we have in Java (and other languages) are to solve 1 of 2 problems. 1.) Complexity. 2.) External code intrusion.

By: Doug

Doug — Mon, 14 Jun 2004 17:08:58 +0000

One place where final classes are needed is in creating immutable value types. If the class isn’t final, someone can create a mutable subtype. This is why java.lang.String, for example, is final… it’s the only way to put immutability into its contract.I do recommend, though, that any such value type implement an (immutable) interface so that the objects can be decorated. This should also allow mock objects to be substituted, although (at least offhand) it seems to me that mocking of value types would be rather unnecessary.