Nope, I think that is exactly the same case. You generally make methods
final because you want users to prevent overriding them. So, when in
future you decide to change your internals, you won't break as many clients.
The reason that abstract classes are more evolvable is that when you
add, remove or change signatures of (final) methods, it won't break
clients (and we put large warnings with most of our final methods not to
use those methods directly), whereas if it would have been an interface,
it would have broken all clients directly, even if e.g. an added method
was just for optional use.
Eelco
Gustavo Hexsel wrote:
Isn't it contradicting that you guys use abstract classes because they are more
"evolvable" and then lock everything with "final" so things don't change as
easily?
[]s Gus
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
