This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Sealed, Unsealed Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

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.