Sealing a class

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?

possible duplicate of [Should I seal all classes I know shouldn't ever be used as a base class?](http://stackoverflow.com/questions/2164170/should-i-seal-all-classes-i-know-shouldnt-ever-be-used-as-a-base-class) — BoltClock, Dec 08 '11 at 16:24

score 5 · Answer 1 · answered Dec 08 '11 at 16:25

5

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.

answered Dec 08 '11 at 16:25

vc 74

37,131
7
73
89

3

You can still follow the open/closed principle with sealed classes by, for example, using composition. One of the recommended good design principles is to favour composition over inheritance. http://lostechies.com/gabrielschenker/2009/02/13/the-open-closed-principle/ – cfwall Feb 27 '12 at 11:32

CodesInChaos · Answer 2 · 2011-12-08T16:41:21.633

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. i.e. 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.

score 3 · Answer 3 · edited May 23 '17 at 12:19

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.

score 2 · Accepted Answer · edited May 21 '13 at 17:33

2

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.

edited May 21 '13 at 17:33

Servy

202,030
26
332
449

answered Dec 08 '11 at 16:25

Justin Niessner

242,243
40
408
536

9

"at some later point in time ... you can seal them then." Only in application code. In library code you can only unseal classes, but not seal them, without breaking code that builds on it. So it's reasonable to seal by default as a library author. – CodesInChaos Dec 08 '11 at 16:28
2

I feel like this is the exact opposite of what should be done. Sealing a class later is a breaking change, unsealing it is not. Unless you've thought carefully about what people might do when they subclass your type, you can introduce the fragile base class problem. – Andy May 21 '13 at 16:13
1

@Andy - You're correct. Unfortunately, the error had been pointed out in the other comment after the answer was accepted and you are unable to delete a post that is considered the accepted answer. – Justin Niessner May 21 '13 at 17:21
@Andy You shouldn't edit a question to just say "see comments". If the comments are that important then edit the question to incorporate the information in them. – Servy May 21 '13 at 17:35
@JustinNiessner, and whoever else might read this: mind helping me out [trying to understand the whole *sealed* concept](http://programmers.stackexchange.com/questions/210461/one-good-reason-to-use-sealed)? – cregox Sep 04 '13 at 17:39
Well... I'd also add: [don't *ever* seal a class unless you *know* you'll have support issues with your clients.](http://programmers.stackexchange.com/a/210481/4261) – cregox Sep 04 '13 at 19:31

score 2 · Answer 5 · answered Dec 08 '11 at 16:26

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?

score 0 · Answer 6 · answered Dec 08 '11 at 16:28

0

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.

answered Dec 08 '11 at 16:28

Eugene

1,515
1
13
23

I understand these basics I was just curious as to what was considered best practice. – CSharpened Dec 08 '11 at 16:31
1

Though it can have protected and virtual members it inherited from its own base. – Jon Hanna Dec 08 '11 at 16:31

Sealing a class

6 Answers6

Linked