So I wanted to inherit from a sealed class in csharp and got burned. There is ju

Question

So I wanted to inherit from a sealed class in csharp and got burned. There is just no way to unseal it unless you have access to the source.

Then it got me thinking "why sealed even exists?". 4 months ago. I couldn't figure it out, despite reading many things about it, such as:

Jon Skeet's wishes "classes were sealed by default in .NET."
Prefer composition over inheritance?
"You should not seal all classes (...)"
How do you mock a Sealed class?
I've tried to digest all that since then, but it's just too much for me. Eventually, yesterday I tried it again. I've scanned over all of them again, plus few more:

Why should a class be anything other than "abstract" or "final/sealed"?
In over 15 years programming, first time I've heard of SOLID, out of an answer from a question already linked and I obviously didn't read it all 4 months ago
Finally, after lots of pondering, I decided to heavily edit the original question based on the new title.

The old question were too broad and subjective. It was basically asking:

In the old title: One good reason to use sealed
In the body: How to properly modify a sealed class? Forget about inheritance? Use composition?
But now, understanding (which I didn't yesterday) that all sealed does is preventing inheritance, and we can and should indeed use composition over inheritance, I realized what I needed was practical examples.

I guess my question here is (and in fact have always been) exactly what Mr.Mindor suggested me in a chat: How can designing for inheritance cause extra cost?

Explanation / Answer

This is not so difficult to comprehend. sealed was created SPECIFICALLY for Microsoft in order to make their lives easier, save tons of money and help their reputation. Since it is a language feature everyone else can use it also but YOU will probably never ever need to use sealed.

Most people are complaining about not being able to extend a class and if they do then they say well everyone knows it is the developers responsibility to make it work correctly. That is correct, EXCEPT those same people have no clue on the history of Windows and one of the problems sealed is trying to solve.

Let's suppose a developer extended a .Net core class (because sealed did not exist) and got it to work perfectly. Yay, for the developer. The developer delivers the product to the customer. The developer's app works great. The customer is happy. Life is good.

Now Microsoft releases a new operating system, which includes fixing bugs in this particular .Net core class. The customer wants to keep up with the times and chooses to install the new operating system. All of a sudden, the application that the customer likes so much no longer works, because it did not take into account the bugs that were fixed in the .Net core class.

Who gets the blame?

Those familiar with Microsoft's history know that Microsoft's new OS will get the blame and not the application software that misused windows libraries. So it then becomes incumbent on Microsoft to fix the problem instead of the application company who created the problem. This is one of the reasons why Windows code became bloated. From what I've read, the Windows operating system code is littered with specific if-then checks for if a specific application and version is running and if so then do some special processing to allow the program to function. That's a lot of money spent by Microsoft to fix another company's incompetence.

Using sealed doesn't completely eliminate the above scenario, but it does help.

Related Questions

Navigate

• Browse (All)
• Browse S
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.