密封一个班级

Question

Sealing a class is not something I have taken much notice of in the past however I find myself wondering what is the best practice. If you know a class would not or should not be derived from would you seal it as a matter of precaution of just leave the sealed keyword out knowing that the chances of someone trying to derive from it are slim.

I guess what I am asking is should you seal all classes which are not intended for inheritance just as a matter of good practice?

Answer 1

If you follow the open/closed principle to the letter, the sealed keyword should never be used. But I guess there are always corner cases.

Answer 2

In application code, where all code that derives from your class is controlled by yourself, I'd leave most classes unsealed by default. If you break code deriving from your class by changing the base class, you can simply fix it.

But sealing is very useful in library code. If you leave a class unsealed, you promise to not break any code that derives from it. ie you increase your public surface area. IMO libaries should keep the surface area minimal by default, which implies sealing.

But it's not always necessary to seal the entire class. It can be enough to seal some or all virtual methods. That way code that derives from your class can only extend it, but not modify its current functionality by overriding a method.

Another kind of class that should often be sealed classes with value semantics. It's much harder to implement correct equality and pseudo mutators for unsealed classes. So I'd simply seal them and avoid the additional work unless really necessary.

Answer 3

I'm not going to give you a straight answer, but here are some things to consider:

Sealed classes might give you a (slight) performance benefit. See this thread:

Do sealed classes really offer performance Benefits?

Sealed classes often interfere with common mocking frameworks which are implemented by subclassing your code.

For further reading:

Why does the 'sealed' keyword exist in .Net?

In practice, I often don't seal classes.

Answer 4

You should not arbitrarily seal all classes that are not, at any given time, meant to be inherited from.

Instead, seal classes that you know should NEVER be inherited from and leave the others open. If, at some later point in time, a decision can be made that those classes should NEVER be inherited from you can seal them then.

Answer 5

The only time I notice a class is sealed is when I really need to derive something from it, but then find out that I can't.

I've never felt the need to seal my own classes. I simply don't think I'm smart enough to know when a class should never be derived. I'm pretty clever, but I can't tell the future.

For core .NET Framework classes to be sealed may make some sense so that they can tightly control the behavior of the framework, but I'v never seen a case where a everyday developer would need to do this. You may want to discourage deriving a class, but sealing it is pretty final, and who knows what your needs will be next week/month/year/lifetime?

Answer 6

Yes, if you want that your class couldn't be inherited you just add the "Sealed" keyword. This class cannot be abstract, can't have protected or virtual methods/fields.