Do you understand ‘sealing’ in C#? Somewhat? Anyway, here’s the lowdown.<\/p>\n
I’ve done this article from a C# perspective, but I’ve occasionally referenced .NET when appropriate.<\/p>\n
By sealing a class in C#, you ensure that you ensure that no class can be derived from that class. You do this by simply adding the word ‘sealed’ to a class definition: public sealed class Dog {}<\/p>\n
Now writing something like ” public sealed class Hamster: Dog {} ” you’ll get a compile error like this:<\/p>\n
‘Hamster: cannot derive from sealed type ‘Dog’<\/p>\n
If you look in an IL disassembler, you’ll see a definition like this:<\/p>\n
.class public auto ansi sealed beforefieldinit Dog extends [mscorlib]System.Object<\/pre>\n<\/p>\nNote the addition of the word ‘sealed’.<\/p>\n
What about sealing methods?<\/h4>\n
You can also seal overriding methods. By adding the word ‘sealed’, you ensure that the method cannot be overridden in a derived class. Consider the following code:<\/p>\n
public class Dog : Mammal { public sealed override void Go() { } }
public class Mammal { public virtual void Go() { } }<\/p>\nIn this code, the method ‘Go’ in Dog is sealed. It cannot be overridden in a subclass. Writing this would cause a compile error:<\/p>\n
public class Dachshund : Dog { public override void Go() { } }<\/p>\n
However, we can ‘new’ a method with the same name. This is essentially a new method; distinct from the ‘Go’ in the subclass:<\/p>\n
public class Terrier : Dog { public new void Go() { } } <\/p>\n
Sealing properties?<\/h4>\n
You can also seal seal properties. You add ‘sealed’ to the property definition, like so:<\/p>\n
public sealed override string Name
{
get { return m_Name; }
set { m_Name = value; }
}<\/p>\nIn C#, you can only seal a property, not the underlying setters\/getters. This is because C# offers no override syntax for setters or getters. However, in underlying IL you seal the setter and getter methods individually – a property is just metadata.<\/p>\n<\/p>\n
Why bother sealing?<\/h4>\n
There are a few traditional reasons to seal:<\/p>\n
\n
- Invariance. <\/strong>Other people may want to derive from your class, even though your implementation may make successful derivation near-impossible. There may be twisted, hacky logic that could never be second-guessed by another developer. By sealing your class, you’re protecting them from wasting their time. The CLR team has sealed most of the framework classes, and I assume they did this for this reason. <\/li>\n
- Security.<\/strong> By deriving from your type, an attacker may gain access to functionality that enables him to hack your system. I consider this a very weak security precaution. <\/li>\n
- Speed.<\/strong> If a class is sealed, then .NET doesn’t need to consult the virtual-function-call table to find the actual type, since it knows that no derived type can exist. Therefore, it could emit a ‘call’ instead of ‘callvirt’ or at least optimise the machine code, thus producing a performance benefit. But I’ve done trials, and have been unable to demonstrate this If you have an example, please share!<\/li>\n<\/ol>\n
All in all, I’m not convinced that sealing is interesting or important. Anyway, moving-on…<\/p>\n
What is automatically sealed?<\/h4>\n
\n
- Value types and structs.<\/strong> If they were not always sealed, all sorts of things would go wrong. For instance, structs are laid-out inline within a class. But what if you assigned a substruct to a struct field of that class? There may be too many fields to fit.<\/li>\n
- Static classes.<\/strong> Static classes exist in C# but not .NET. The C# compiler compiles a static class into an ‘abstract sealed’ class. So static classes are already sealed in C#.<\/li>\n
- Enumerations.<\/strong> The CLR does not track the types of enumerations – it treats them as simple value types. Hence, polymorphism would not work.<\/li>\n<\/ol>\n
What cannot be sealed?<\/h4>\n
\n
- \n
Interfaces.<\/strong> Interfaces exist to be implemented, so sealing to prevent implementation is dumb. But what if you could prevent interfaces from being extended (i.e. ban declarations like “public interface IMyInterface : ISealedInterface”)? There is no good reason to seal an interface like this. Sealing finalizes behaviour, but interfaces have no intrinsic behaviour to finalize<\/p>\n<\/li>\n
- \n
Abstract classes.<\/strong> In IL you can<\/em> create an abstract sealed class. But C# syntax for this already exists – declaring a class as a ‘static’, so it forces you to declare it as such.<\/p>\n<\/li>\n
- \n
Non-override methods.<\/strong> If a method isn’t declared as override it cannot be overridden, so sealing would make no difference. Note this is stated from a C# perspective – the words are opposite in IL. In IL, you have four choices in total: no declaration (which actually seals the method), ‘virtual’ (called ‘override’ in C#), ‘sealed virtual’ (‘sealed override’ in C#) and ‘newslot virtual’ (‘new virtual’ or ‘virtual’ in C#, depending on whether the method already exists in a base class).<\/p>\n<\/li>\n
- \n
Methods that implement interface methods.<\/strong> Methods that implement an interface method must be virtual, so cannot be sealed.<\/p>\n<\/li>\n
- \n
Fields<\/strong>. A field cannot be overridden, only hidden (using the ‘new’ keyword in C#), so sealing would make no sense.<\/p>\n<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Do you understand ‘sealing’ in C#? Somewhat? Anyway, here’s the lowdown. I’ve done this article from a C# perspective, but I’ve occasionally referenced .NET when appropriate. What is sealing a class? By sealing a class in C#, you ensure that you ensure that no class can be derived from that class. You do this by……<\/p>\n","protected":false},"author":95472,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"coauthors":[],"class_list":["post-3043","post","type-post","status-publish","format-standard","hentry","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3043","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/95472"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=3043"}],"version-history":[{"count":2,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3043\/revisions"}],"predecessor-version":[{"id":41884,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3043\/revisions\/41884"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=3043"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=3043"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=3043"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=3043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}