More thoughts on sealed/final
There's been a lot of talk about sealed/final since I posted here. In various posts (like this one from Ted Neward, the assertion is made that languages like Java and C# (any CLR based language, actually) need this capability, while Smalltalk doesn't. That sounded wrong to me, but I'll get to it. The other argument came across in a brief conversation I had with Joshua Bloch after this talk at ot2004. The argument goes like this: There's a pyramid of developers, with elite developers at the top (in small numbers) - with most living at the bottom two rows of the pyramid. making classes "final" protects this class of developer from themselves. I've pondered these two arguments, and had a few conversations about them on the Smalltalk IRC channel, with people who have experience with Smalltalk, Java, and C#. Here's what we came up with:
In Java, interface inheritance is the way to do things. A change in the API or semantics of the interface will ripple through all users - even though they aren't inheriting from the base class. So exactly what have you saved people from? Nothing except the option to inherit from a class if they wanted to take on that responsibility. So posit a class SecurityChecker and a method checkPassword(). That method should only take an instance of String, not some subclass or compatible class. That kind of security is arguably ok - but making it impossible to subclass String for any reason, ever - is overkill. The controls belong at a finer grain. What "final" ends up doing is cutting off your nose to spite your face. Here's a question: who's in a better position to know whether subclassing is appropriate:
- The library developer who has never seen the end developer's code
- The end developer who has seen both the framework and the end developer code?
Ted and Joshua Bloch say the library designers are in the better position. I say that's just silly - it really is akin to deciding that you are going to protect your children from all possible harm that could come to them by standing next to them 24x7. Sure, they'll be better protected. They'll also grow up as less than adults. This kind of protection means that developers have lots of (potentially better) options closed off to them, and they'll create crufty code. Worse, they'll start thinking that it's a good idea. The protection extended to them has ended up crippling them.
So now we come to arguments that Whidbey (the next gen of VisualStudio) should declare classes final by default, forcing developers to open them if they so choose. For the reasons given above, I think this is an awful idea. It will end up creating inflexible code - and since api changes ripple through a declared interface anyway, it offers few of the supposed benefits. I really have no idea why anyone thinks this is a good idea...
Comments
enabling versus directing
[keith ray] April 20, 2004 12:31:59.118
see http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html
object oriented spaghetti
[bryan] April 20, 2004 14:25:01.883
Wasn't it Paul Graham who said something about Object-orientation being a maintainable way of writing sphaghetti code. It seems to me that this is the way the big companies see OOP and that their viewpoint presupposes objects created by geniuses and accessed by dullards. Even a fully informed dullard is apt to be wrong more often than a guessing genius therefore we must protect the conceptual framework of our geniuses from disturbance by our dullards.
assumptions & experiences
[Isaac Gouy] April 20, 2004 15:09:11.828
Maybe we could step back from our judgements and wonder how well meaning people could think such different things. Probably we are all making some unstated assumptions based on our particular experience of software development. The big unstated assumption in this conversation - Is the component (library) developer responsible for the continued correct operation of client code when a new component (library) version is released? http://www.artima.com/intv/nonvirtual2.html How we answer this probably depends on how much experience we have delivering component software - having customers scream down the phone that the latest version of our component (library) broke their critical applications, may color our views. How we answer this probably depends on how much experience we have rapidly extending software - knowing that we could make a critical change during an important software demonstration if only we could subclass that component, may color our views. This isn't a yes/no issue - it's a design trade-off contingent on assumed usage.
C# has problems anyway
[Sean Malloy] April 20, 2004 23:58:48.281
C# is unlike java in that methods are not implicitly virtual. You have to manually place a virtual keyword on the method declaration for subclasses to override the method anyway. Most developers don't explicityly virtualise all of their method declarations, so the C# developers of the world are probably getting the rawest deal. Once again, implicity non-virtual methods was done for two reasons. Performance, and to ease developer pain. It seems to me a lot of features get added to ease developer pain, and all they do is cut off developers limbs! I don't want to go to any doctor like that.. "Hey doc, I keep getting cramps in my calf... " "Ok, well in this situation, we'll amputate. It will save you a lot of pain in the long run"
Library developers vs. other developers
[Rob Meyer] April 21, 2004 10:10:19.233
I don't think the argument is so much for making library developers block inheritence; they are designing a library so they will spend the time and effort to make their code sub-classable (by careful design and documentation), because that's what people want to do with libraries. When you have carefully planned for inheritance, that's fine. I think the point is concentrating on end code written by the lower-tier developers that you mention. When that type of code is written, perhaps it should be final/sealed by default. Because undoubtably the bulk of developers will not take the time to make things subclassable easily or properly. So later another lower tier maintenance programmer will come along, not realize the issues in subclassing that other code, and your problems will begin. Not that making final the default will perfectly solve the problem, but it does make the argument more coherent if you frame it this way.
Re: More thoughts on sealed/final
[Robert Church] April 21, 2004 13:24:21.636
Comment on More thoughts on sealed/final by Robert Church
Okay, so the argument boils down to this:
"Bad developers might abuse this powerful feature and create brittle, difficult to maintain software. To solve this problem, we'll take away this powerful feature and *force* them to create brittle, difficult to maintain software."