How can designing for inheritance cause extra cost?

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:

1. In the old title: One good reason to use sealed
2. 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?

Answer 1

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.

Answer 2

sealed is used to indicate that the writer of the class hasn't designed it to be inherited. Nothing less, nothing more.

Properly designing an interface is already difficult enough for lots of programmers. Properly designing a class which can be potentially inherited adds difficulty and lines of code. More lines of code written means more code to maintain. To avoid this increasing difficulty, sealed can show that the class was never intended to be inherited, and in this context, sealing a class is a perfectly valid solution to a problem.

Imagine the case where the class CustomBoeing787 is derived from Airliner. This CustomBoeing787 overrides some protected methods from Airliner, but not all of them. If the developer has enough time and it's worth it, he can unit test the class to ensure that everything works as expected, even in a context when non-overriden methods are called (for example protected setters which change the state of the object). If the same developer (1) doesn't have time, (2) doesn't want to spend additional hundreds or thousands of dollars of his boss/customer, or (3) doesn't want to write additional code he doesn't need right now (YAGNI), then he can:

• either release the code in the wild as is, considering that it's the concern of the programmers who will maintain this project later to care about potential bugs,

• or mark the class as sealed to explicitly show to the future programmers that this class is not intended to be inherited, and that unsealing it and using it as a parent should be done at your own risk.

Is it a good idea to seal as many classes as possible, or as few as possible? From my experience, there is no definitive answer. Some developers tend to use sealed too much; others don't care about how the class would be inherited and the problem it can cause. Given such usage, the problem is similar to the one which consists in determining whether programmers should use two or four spaces for indentation: there is no right answer.

Answer 3

When a class is sealed it allows code using that type to know exactly what they're dealing with.

Now in C# string is sealed, you can't inherit from it, but let's assume for a second that that wasn't the case. If you did, then someone could write a class like this:

public class EvilString// : String
{
    public override string ToString()
    {
        throw new Exception("I'm mean");
    }
    public override bool Equals(object obj)
    {
        return false;
    }
    public override int GetHashCode()
    {
        return 0;
    }
}

This would now be a string class that is violating all sorts of properties that the designers of string knew to be true. They knew that the Equals method would be transitive, this is not. Heck, this equals method isn't even symmetric, as a string could be equal to it but it wouldn't be equal to that string. I'm sure there are all sorts of programmers who have written code under the assumption that the ToString method of string won't throw an exception for non-null values. You will now be able to violate that assumption.

There are any number of other classes we could do this for, and all sorts of other assumptions that we could violate. If you remove the language feature for sealed then the language designers now need to start accounting for things like this in all of their library code. They need to perform all sorts of checks to ensure that extended types of the types they wish to use will be written "properly", which can be a very expensive thing to do (both in dev time, as well as at run time). By being able to seal a class they can ensure that this isn't possible, and that any assertions they make about the implementation details of their own types can't be violated, except for those types that are intentionally designed to be extended. For those types designed to be extended you'll find the language code needs to be much more defensive about how it deals with them.

Answer 4

First of all, you should read Eric Lippert's post on why Microsoft seal their classes.

Link

Secondly, the sealed keyword exists to do exactly what it does - prevent inheritance. There are many situations where you want to prevent inheritance. Consider a class that you have a collection of. If your code depends on that class working in a particular fashion you don't want someone overriding one of the methods or properties in that class and causing your application to fail.

Thirdly, using sealed encourages composition over inheritance, which is a good habit to get into. Using composition over inheritance means that you can't break Liskov's substitution principle and you're following the Open/Closed principle. sealed is therefore a keyword that assists you in following two of the five most important principles of o-o programming. I'd say that makes it a very valuable feature.

Answer 5

Is there any good reason to use sealed?

Enh? Not often. I will only used sealed when I have an immutable type (or some other limitation) that really really needs to remain immutable and I cannot trust inheritors to furfill that requirement without introducing subtle, catastropic bugs into the system.

Suppose there is a good reason to use sealed and we should use it as default for everything, what we do with inheritance?

We use inheritence for those things that are not default. Even if composition is favored over inheritence (and it is), that doesn't mean inheritence is to be discarded. It means that inheritence has some intrinsic problems that it introduces into design and code maintainability and composition does much of the same thing with (in general) less problems. And it means that even if composition is favored that inheritence is good for certain subsets of problems.

I don't mean to be too mean but if you've just now heard of SOLID and unit testing, maybe you should get out from underneith your rock and actually write code. Things aren't clear cut, and rarely will "always do X" or "never use Y" or "Z is best" be the right way (like it seems you gravitate towards based on your question's views). As you write code you can see cases where sealed could be good and cases where it causes you grief - just like any other tradeoff.

Answer 6

I think this question doesn't have objective answer and that it all depends on your perspective.

One side, some people want everything "open" and burden of ensuring everything is working correctly is on person who extends the class. This is why classes are open to inheritance by default. And why Java methods are all virtual by default.

On the other side, some want everything to be closed by default and to provide options to open it. In this case, it is base class's author who needs to ensure everything he makes "open" is safe to use in any way imaginable. This is why in C# all methods are non-virtual by default and need to be declared virtual to be overriden. It is also for those people, that need to be way to circumvent "open" defaults. Like making class sealed/final, because they see someone deriving from the class a big problem to their own class's design.

Answer 7

the problem with sealed in C# is that its rather final. In 7 years of C# commercial development, the only place I have seen it used is on Microsoft .NET classes where I feel I had a legitimate reason to extend a framework class to implement adjusted behaviour, and because the class was sealed, I could not.

It is impossible to write a class thinking about every possible way it could be used, and deciding that none of them are legitimate. Likewise if framework security is dependent on the class not being inherited, then you have a security design flaw.

So, in conclusion, I'm firmly of the view that sealed serves no useful purpose, and nothing I have read here so far has changed that view.

I can see there have so far been three arguments that justify sealed placed so far.

1. Argument 1 is that it eliminates a source of bugs when people inherit from classes and then have increased access to the internals of that class without really understanding the internals properly.

2. Argument 2 is that if you extend a microsoft class and then microsoft implement a bug fix in that class but your extention relied on that bug then your code is now broken, microsoft gets the blame, and sealed prevents that

3. Argument 3 is that as the developer of the class, its my choice whether to allow you to extend it, as part of my design of the class.

Argument 1 seems to be an argument that you the end programmer don't know how to use my code. That may be the case, but if you still allow me to access the objects interface it still holds true that I am using your object, and making calls to it without understanding how to use it, and so can make just as much damage that way. This is a feeble justification of the need for sealed.

I understand where the factual base for arg 2 comes from. In particular when microsoft put additional OS checks on win32 api calls to identify malformed calls, which have improved the general stability of the Windows XP compared to Windows NT, but at the short term cost that many apps were broken when Windows XP was released. Microsoft resolved this by putting 'rules' in for these checks to say, ignore when app X breaks this rule, its a known bug

Argument 2 is a poor argument because sealed at best makes next to no difference to this because if there is a bug in the .NET library you have no choice but to find a work around, and when the microsoft fix comes out, its quite likely means that your work around which depends on the broken behaviour is now broken. Whether you worked around this by using inheritance or by some other additional wrapper code, when the code is fixed, your work around will be broken.

Argument 3 is the only argument that has any substance to justify its self. But it is still weak. It just goes against the grain of code reuse.

Answer 8

I only use sealed keyword on classes that contain only static methods.

Answer 9

As evident by my question, I'm no expert here. But I see no reason for sealed to even exist.

It seems to be made to help code architects to design an interface. If you want to write a class that will go out in the wild and many people will inherit from it, modifying anything in that class can break it for too many people. So we can seal it and nobody can inherit. "Problem solved".

Well, looks like "covering a spot and uncovering another". And it's not even solving a problem - it's just eliminating a tool: inheritance. As any tool, it has many usages and inheriting from a unstable class is a risk you take. Whoever took that risk should know better.

Maybe there could be a keyword stable, so people would know it's safer to inherit from it.