Why all the final methods?

[Cuno]

I've been using AbstractWizardFormController twice now (i'm a newbie to spring, yes), and in both cases some page of the wizard had more than one form, for example a checkout bean where the customer may edit quantity in the basket before continuing. But since processFormSubmission is final, i'm forced to do the in-page form processing in the getTargetPage method. A very ugly solution.

My collague has some similar issues with the RedirectView.renderMergedOutputModel, which apparently wasn't final in the 1.0 release.

Isn't it true that final in the method declaration has very little (if any) impact on the performance? I have a feeling i've read something like that somewhere... I would appreciate less use of final methods.

[klr8]

I also noticed this and I was asking the same question. On the one hand Spring tries to bring as much flexibility as possible to the developer and on the other hand they are forcing certain behaviour by declaring methods final.

I guess this is done to really force a particular kind of behaviour in base framework classes like AbstractWizardFormController. That makes it easy for anyone with Spring knowledge that looks at your code to understand what the AbstractWizardFormController is doing, there is no way to completely change the behaviour of such a class by subclassing it and redefining the core workflow methods.

Spring Team, care to comment?

Erwin

[Ben Alex]

There is a detailed discussion on this issue in Rod's first book (J2EE Design and Development) on page 153.

I recommend making public and protected non-abstract methods final. This can help to eliminate a common cause of bugs: subclasses corrupting the state of their superclasses. Overriding methods is inherently dangerous.

It goes on to discuss the OO Open Closed Principle and acknowledge the slight performance gain of final is too marginal to be of consideration in most cases.

There are also recommendations on how to provide hook methods. You see this throughout Spring. In unit testing for example, the new AbstractTransactionalSpringContextTests marks onSetUp() as final, but in that implementation it provides a onSetUpInTransaction() for subclasses to use.