I understand the motivation for making individual methods of a class sealed/final, but what purpose does completely prohibiting inheritance from the class serve? While allowing overriding of certain methods can cause bad things to happen, I can't see how allowing inheritance from your class purely to add behavior to it without overriding existing behavior could ever be a bad thing. If you really want to disallow overriding anything in your class, why not just make every method final but still allow inheritance for the purpose of adding behavior?
views:
129answers:
5
+3
A:
There are some good discussions about this in the "Why String is final in Java" question: http://stackoverflow.com/questions/2068804/why-string-is-final-in-java
The basic summary in that case is, String is immutable, and if it could be subclassed, the subclass might make it mutable.
Ray Hidayat
2010-01-30 22:20:38
+1
A:
Think about it this way: You spent your last 3 months working on a base class for your own framework that others are going to use, and the whole consistency of the framework is based on the code written in this class, modifying this class may cause bugs, errors, and misbehavior of your framework, how do you prevent your great programmers from extending it and override one of its methods?
In addition to this there are class that are supposed to be immutable, such as the java.lang.String class in Java, extending it and changing its behavior could make a big mess!
Finally sometimes setting a class or method as final will increase performance, but I never tested it, and don't see any reason on earth to make a class/method final for a very very tiny performance gain that is equal to zero compared to the time needed to do other stuff in the program.
Omar Al Kababji
2010-01-30 22:24:10
1. The question is about allowing subclassing to add behavior. I understand why you would want to prohibit overriding. 2. If a class takes you 3 months to write, it probably does way too much.
dsimcha
2010-01-30 22:25:29
Don't take 3 months literarily, the idea was an important class, in a fragile context, and where every other class expects that it will obey a certain behavior.
Omar Al Kababji
2010-01-30 22:29:00
+3
A:
More generally, a class can be made final in order to preserve the invariants that make it work. I highly recommend Joshua Bloch's "Effective Java" for an excellent discussion on this and related issues.
Steve Emmerson
2010-01-30 22:28:25
+1
A:
An organisation/software dev team might want to enforce certain coding standards. For example, in order to improve readability, they might only want attribute X of class Y to be modified with method Z and nothing else. If the class were not final, some developer might extend class Y and add method W, which could modify X in a different way and cause confusion and delay when it came to comprehending the code written.
Jimmeh
2010-01-30 23:05:53
A:
I think it depends.
If I have an internal application I wouldn't use the final on class level by default. Code just gets too cluttered. In some circumstances final modifier is even really annoying, if I want to refactor safely (see the programming by difference term). In some cases the 'default-final-mania' made big problems when I tried to refactor.
On the other hand if I design an api/framework where code is more extension-driven I would use final for classes 'more aggressively'. Here wrong extension can be a big problem and the 'final' modifier is a safe way to avoid such programming mistakes.
But I am just opposed to say use 'final' by default like many do. It has often more drawbacks as advantages. To me defaults should be 'sensible and more common setting'.
manuel aldana
2010-01-31 10:08:00