Re: Is 'Final' for classes and methods a good feature or something that should be eliminated?

Michael Feathers <mfeathers@xxxxxxxxxxxxxxxx> wrote:

It's not just a simple matter of being annoying. Final can make code
untestable.

The sad fact is that API designers don't yet know how to use it without
rendering code untestable.

I think blame is being placed incorrectly in this case. It isn't 'final'
that is causing the problem.

Let's look at the example again... We have a class that contains a
method that causes some side effect that the test harness doesn't want
occurring during testing. There is several problems here without ever
even mentioning the word final. If the side effect is part of the
documented behavior of the method, then I expect that any class that
calls the method needs that side effect to happen for it to be
considered correct. If that isn't the case, then the real problem has
nothing to do with final, it has to do with the fact that no interface
was defined for the user to use. After all, if the user doesn't depend
on the documented effects of the method for correct operation, then it
shouldn't care what class the object it sends its message to is.

It sounds to me like the blame should be placed on the lack of an
interface for the client to use, not in the fact that this particular
server isn't designed to be sub-classed.

I think, instead of insisting that 'final' is at fault, you should be
insisting that interfaces be more prevalent in the library in question.
.