7

Reading this article (by Eric Lippert), it has four arguments as to why you should use sealed, however, I don't understand why we actually need it. Philosophical/aesthetic reasons aside, why do we need to use sealed?

I can see how things like readonly from C# or const from C++ actually catch genuine errors. Is there any type of error that sealed can catch?

An often cited reason for sealing a class is because, it hasn't been to designed to be extended. What does that mean? Why is it important? Are there any real examples of this?

The point on compatibility isn't a reason why we need to seal classes but why it should be default.

The final point again is strange, because sealing your class doesn't prevent someone providing an alternative implementation in a heirachy.

Edit:

If I didn't put enough emphasis, on it already I'm looking for reasons we actually need it. Not the usual, "someone else might write bad code". I understand that plenty of people like using sealed for design intent, but I'm looking for a practical purpose beyond that.

|improve this question
  • The explicit purpose is to prevent a class from being inherited. If I make a class Car that inherits from class Giraffe I'm saying that cars are giraffes and that may have implications the writer of Giraffe never coded for resulting in system instability. I'm not saying someone can't offer an alternative implementation, they just can't paste it over an existing one that wasn't designed to account for that. – Kevin Jan 9 '14 at 21:19
  • 1
    Related How can designing for inheritance cause extra cost – user40980 Jan 9 '14 at 21:20
  • 1
    Are you able to write a C# program without using it? If so, you don't 'need' to use it. – GrandmasterB Jan 9 '14 at 22:50
  • Eric thinks from the point of view of a library developer. If a change to a library breaks a consumer, the library author can't make that change anymore. So it's useful to restrict a consumer from using it in a way that you're not willing to support. Restricting the consumer increases the flexibility of the library developer. – CodesInChaos Jan 10 '14 at 12:46
  • Not every language feature is something that you need. Sometimes, they're just nice to have, offering a syntactic or semantic alternative to a solution that might be more cumbersome. – KChaloux Jan 10 '14 at 14:11
4

What does that mean?

It means that it is difficult for people to obey the Liskov Substitution Principle (or less likely, the Open Closed Principle) with the class as is. It has subtle, or difficult to enforce behavior that inheritors are likely to screw up. Or they're not likely to screw up, but the impact of screwing them up is huge.

The final point again is strange, because sealing your class doesn't prevent someone providing an alternative implementation.

Sure it does. If some method takes object A or some other class uses type A, by having A sealed, people cannot override it with B and then pass B into the method or use it in the class. Consumers of A can see it's sealed and know that A is the only behavior they're getting.

All that said, we don't need sealed - just like we don't need readonly. They are tools to help programmers prevent misuse, because misuse leads to bugs. Though personally, I dislike sealed; even in these days where composition over inheritence is well known, it is rare that you can say "nobody will ever need to extend this" and actually be right.

|improve this answer
2

Reading around I've found a few things, a bit less abstract than LSP violations (although they could be considered to be):

  • An immutable type which is subclassed may become mutable (bad for multi-threading, etc)
  • Polymorphic equality, you can then guarantee that the types are the same and not just equivalent.

Sealing classes also offers some Runtime/Reflection performance improvements

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.