"There are those who think that a language should prevent programmers from doing stupid things, and those who think programmers should be allowed to do whatever they want." [Hackers & Painters by Paul Graham]
Imagine, you are implementing a DbExecutionStrategy for Entity Framework and you are thinking: Let me inherit this SqlException, so I can create a ThrowTimeOutExpiredSqlException and use this to test my execution strategy... a bit later you realise the class is sealed... bummer... ok let's just use the SqlException class itself and hopefully find the correct properties to make it behave the way I want... bummer again... it seems all the constructors are private... but wait it seems there are some factory methods called CreateException... I am sure that's what I need to use... euh or not since they are marked as internal.
I guess by now you realise I am belonging to the group of developers that thinks programmers should be allowed to do whatever they want.
So why make things so difficult? Why would I want to make things sealed, internal or even non-virtual?
- Speed optimization
- Security considerations
- Ensuring immutables don't become mutables
- Prevent inheritance fragility
OR...
Because I am to 'lazy' to design the class for inheritance and sealed effectivily says: "The writer of this class did not design this class to be inherited. Nothing less, nothing more."
Of course we need to read lazy as: I am working for a company and I have no time to implement all these other members and think of all the edge cases you might use this class for. Moreover if you inherit my stuff and then it breaks when I change stuff I have to work more and therefor spend more company money... and I think that's the main reason: Maintainability of legacy projects.
And this is also the reason many of the microsoft framework classes are sealed and have internals. Microsoft tries to prevent developers from using things they probably will change or not support in future versions. And if they would allow developers from using them, they would probably break the software when the user does the next windows update. And guess who get's the blame at that moment.
Maybe we should invent an attribute to mark classes with [I_Consider_This_Sealed But_I_Am_Leaving_You_The_Freedom To_Change_It] or some other way to express our intentions. Until then I believe that if you extend a class it's your problem if you break it. Start writing more unit tests.
Anyway, I solved the SqlException thing by using reflection to access the method and I for sure will blame microsoft if they change this method in future EF versions :)
More about seals:
ps: Most of the time I favor composition over inheritance.
ps2: Did you know static classes are actually sealed classes? Maybe that's why I don't like those either...