6

If a class doesn't have any virtual methods, I do not see any way inheriting a class would affect any code that doesn't explicitly refer to the instance as an instance of the subclass i.e. 

Subclass obj = new Subclass()

rather than 

BaseClass obj = new SubClass()

So therefore, why does sealed even exist?

If you're not declaring anything as virtual (which I see no point in doing in a sealed class) all it prevents is things like (for example) a ListViewItem that stores some extra information about what it represents for code that "knows" that information is there, which has no impact on code that wasn't written with that subclass in mind, unlike an overridden method.

Jonny
  • 2,509
  • 23
  • 42
flarn2006
  • 1,787
  • 15
  • 37
  • 1
    There are more 'obvious' answers, but what if a class is implemented on top of the CLR directly rather than in C# code and extending it would break it? – Benjamin Gruenbaum Mar 14 '14 at 01:31

3 Answers3

6

(1) Sealed class

I may have a method that accepts an object of type BankAccount. I don't want you to be able to create EvilBankAccount : BankAccount and pass it into my method. EvilBankAccount could potentially break my system which makes assumptions about a BankAccount -- for example, that it can be serialized. Maybe I clone BankAccount to prevent external manipulation once it is submitted, and EvilBankAccount clones just fine, but starts a timer in its constructor that auto-increments the balance every 30 seconds.

(2) Sealed member

You can override a virtual method or property, but seal it so that it cannot be overridden further in the inheritance hierarchy. One use case here is when you need to access the member from your constructor.

Jay
  • 56,361
  • 10
  • 99
  • 123
  • 1
    I'm not sure I buy into this 'EvilBankAccount' bit, if I really want to invoke your method - can't I just use reflection? – Benjamin Gruenbaum Mar 14 '14 at 01:32
  • Call the method with reflection, if you wish, but you still can't create and pass in anything that derives from `BankAccount` if I've sealed it. – Jay Mar 14 '14 at 01:36
  • I would agree that it's not so much of a trust or security issue as it is a way to prevent misuse of an API that could render it non-functional. However, that's not the essence of the answer. – moribvndvs Mar 14 '14 at 01:40
  • But if the `BankAccount` parameter isn't specifically declared as `EvilBankAccount`, what effect would method hiding have? And what do constructor parameters have to do with it, if the method is accepting an already-constructed object rather than calling `new` itself? – flarn2006 Mar 14 '14 at 03:47
  • Sealing `BankAccount` would also limit any possibility to create derived types for automatic testing. The described scenario more about code security, why would your secure code create instances of `EvilBankAccount`? – sisve Mar 14 '14 at 05:16
0

Consider 

class A
{
  public virtual void M1();
  public void M2();
}

class B : A
{
  public override sealed void M1();
}

sealed class C : A
{
   //other stuff    
}

class D : A
{
   public new void M2(); //marking A as sealed would prevent this 
}

See also: Do sealed classes really offer performance Benefits? (JITter can optimize certain calls when it knows there can be no subclass)

Community
  • 1
  • 1
Mark Sowul
  • 10,244
  • 1
  • 45
  • 51
0

I personally don't benefit much from sealed classes, and agree, it can be frustrating when dealing with UI classes and want to just add some custom behavior through inheritance. However, I found an answer here that offers a few ideas.

Why seal a class?

Community
  • 1
  • 1
TGH
  • 38,769
  • 12
  • 102
  • 135