Sealing a class

views:

199

answers:

+5 Q:

Possible Duplicate:
Why seal a class?

Why would I want my class to be sealed? Somehow it does not make sense to me. If someone want to inherit from my class that's his/her business and I have no desire to poke my nose in it. It somehow sounds artifficial to me and it seems that it is somehow against code reuse. Why would anyone want to do it? What is my gain in doing so except restricting others (And I know that I'm going to be slagged like hell but I have to ask it anyway because I'm really curious).

I agree - in fact, there have been times that I have needed to inherit from 3rd party classes, and it would have caused all kinds of grief if those classes had been declared sealed.

It was also nice that the 3rd party classes had declared most everything as either public or protected, so the code lended itself well to tweaks.

Justin Ethier 2010-06-10 13:17:10

+1 A:

A class has to be designed for inheritance.
If I got a property that has a public getter, but a private setter you can't modify it in a derived class anyway. So what would you propose? To make all private property setters just protected?
What about fields, do you make them protected, too? In this case - how do you implement certain expectations - like: after this field is modified, the private method Refresh() has to be called. A derived class could just ignore this expectation and cause misbehaviour.
In multithreading scenarious it could be even more difficult - think about correct locking.
Of course you could argue, that a class has to be implemented in a friendly way for anyone who wants to derive it. But that's exactly my first point - it has to be done intentionally. The documentation has to be accordingly.
And if a developer doesn't design it this way, he should seal it to make it less errorprone.

tanascius 2010-06-10 13:22:19

@tanascius fields should be private, class interface should be public, helper methods should be private. You as a class designer should take every care of it that class would not misbehave. But not put any artificial constrain on future developers because you possibly can't foresee every situation in which someone may want to use your class.

There is nothing we can do 2010-06-10 13:27:46

@Knowi: but there are different causes for misbehaviour. Misbehaviour by using the class is just a bug, that's what we always care about. But misbehaviour caused by inheritance is different - the possibilities are more difficile and complex. You have to think about the usage as a baseclass more carefully.

tanascius 2010-06-10 13:32:56

@tanascius I'm sorry but IMO either class is well design and in that case inheriting it wont cause problems or is not well design and then it becomes "to precious" (read to fragile) and anyone who inherits from it could get hurt. I would like to see one of your classes that you sealed, listen to your reasoning why you did that and what harm can be done otherwise. I wonder if you would willing to do so.

There is nothing we can do 2010-06-10 18:27:37

@Knowi, I will try to find an example tomorrow ...

tanascius 2010-06-10 21:46:30

@tanas Ok looking forward to see it and have a chat about it

There is nothing we can do 2010-06-11 09:15:00

@Knowing, your starting premise is that the inability to be safely inherited indicates bad design, so, by definition, any class that fails your test is badly designed. All that failing the test means, however, is that the class is badly designed for inheritance, which is exactly why it should be sealed, so that this is no longer a design consideration.

Dan Bryant 2010-06-11 13:51:11

ansaurus

tags:

views:

answers:

Sealing a class

related questions