Sealed, Unsealed
Ted Neward argues in favor of sealed classes:
Look at it this way: take a simple example, that of overriding a method. What can you do in the base class to ensure that a future derivative doesn't somehow break your class' contract? Should derivatives call the base class method? And *when* should they make that call? At the start of their override? The end? Somewhere in the middle? What about synchronization concerns? Type compatibility? Are you really fully prepared to ensure that the Liskov Substitution Principle is honored in all its forms? From my experience, not many developers even know what Liskov is, much less what it's supposed to be doing for you.
Here's the simple answer: Why do I care? If another developer picks up my code, and wants to extend it by subclassing, it's not my problem - it's his. I'm going to make the assumption that said developer either
- Knows what he is doing
- Doesn't know, and will learn from his mistake
To my mind, stating that classes should be sealed is like saying that you should protect your kids from each and every mistake they might make someday. It might make you feel better, but it does positive harm to the people involved. Let other developers make their own decisions - making them for them is no favor.
Comments
Not a great advertiserment for your product
[Shane King] April 17, 2004 23:50:24.166
If you don't care about making things easy for the people who are going to use the classes you create, I'm damn glad I don't have to use any of the code you create. As an API designer, you should care about the uses of your code. You should care whether it's safe to extend or not. You should care whether the next version is going to make some changes that breaks existing clients. If you don't, you're pushing a problem onto every single user of your code (potentially millions of developers, if smalltalk ever catches on like you hope for). All because you "don't care" whether it's easy for users of your code, because they should be mind readers/clairvoyants and know exactly what is and isn't safe to do with your code, including any future revisions made to it.
Re: Sealed, Unsealed
[James Robertson] April 17, 2004 23:58:34.376
Comment on Sealed, Unsealed by James Robertson
You miss my point completely, although that's likely due to the way I wrote the message. I can't possibly know how other people are going to use code I write. I can't possibly know what their needs are. I can say - based on the experience of people picking up my code - that they often use it in ways I didn't foresee. In order to do that, they've needed to extend my code. In the sealed mindset, that's just impossible...
Re: Sealed, Unsealed
[Troy] April 18, 2004 9:21:58.039
Comment on Sealed, Unsealed by Troy
This is a mindset and world view thing, see my post. I can't recall any Smalltalker I've worked with considering themselves as writing an "API." I am beginning to think that this cultural divide, reinforced by tools, is unsurmountable.
Do no harm
[Isaac Gouy] April 18, 2004 11:17:01.024
"likely due to the way I wrote the message"
Yup.
Try an explanation in terms of a doctors first duty to do no harm.