Nice article and completely agree that virtual is a smell outside of libraries and such, and even in them if inheritance is used improperly. However, I also consider final, sealed, and the like to be a smell, but sealed as default (in languages that doesn't provide a way to override the seal) is an even greater stink.
Outside specific design requirements, marking something as sealed provides no benefit and pointlessly removes a tool that could be used later by consumers of the product.
Say I need to interop with your program, or with data files it outputs. So I reference your application in mine and attempt to reuse as much logic and infrastructure as possible. However, since my project doesn't have the same purpose as yours, I need to tweak a tiny bit of logic. Now, I could have simply inherited from one of your classes, tweaked a single method, and passed it along to your logic, happy as could be...
Only, I can't, because the devs of your project were seal happy. Instead, if I'm lucky, the stars align, and the language allows, then I can spin some reflection magic to bypass your seal. If I'm not lucky, I have to recreate a bunch of logic and code.
I guess all of that is ok if it offset by some benefit, but there is no benefit to sealing general things other than a vague idea that it might discourage over use of inheritance.
As with anything else in the coding world, if you mark something as sealed, then you should have a specific reason for doing so. If there isn't a specific need for the thing to be sealed, then don't seal it. No user or consumer is ever helped by a thing being sealed, but there is a chance they might be hampered by it.
Don't agree that sealed by default doesn't provide value though. The value is enforcing as much as possible that the code is used as it was intended to, minimizing the surprise factor when doing something it wasn't originally designed to do.
But of course, this has the problem of not allowing simple tweaks, as you mentioned, which could have no unintended side effects, but fix a given problem.
As usual, trade-offs 🙂.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article and completely agree that virtual is a smell outside of libraries and such, and even in them if inheritance is used improperly. However, I also consider
final,sealed, and the like to be a smell, but sealed as default (in languages that doesn't provide a way to override the seal) is an even greater stink.Outside specific design requirements, marking something as sealed provides no benefit and pointlessly removes a tool that could be used later by consumers of the product.
Say I need to interop with your program, or with data files it outputs. So I reference your application in mine and attempt to reuse as much logic and infrastructure as possible. However, since my project doesn't have the same purpose as yours, I need to tweak a tiny bit of logic. Now, I could have simply inherited from one of your classes, tweaked a single method, and passed it along to your logic, happy as could be...
Only, I can't, because the devs of your project were seal happy. Instead, if I'm lucky, the stars align, and the language allows, then I can spin some reflection magic to bypass your seal. If I'm not lucky, I have to recreate a bunch of logic and code.
I guess all of that is ok if it offset by some benefit, but there is no benefit to sealing general things other than a vague idea that it might discourage over use of inheritance.
As with anything else in the coding world, if you mark something as sealed, then you should have a specific reason for doing so. If there isn't a specific need for the thing to be sealed, then don't seal it. No user or consumer is ever helped by a thing being sealed, but there is a chance they might be hampered by it.
That's a valid point.
Don't agree that sealed by default doesn't provide value though. The value is enforcing as much as possible that the code is used as it was intended to, minimizing the surprise factor when doing something it wasn't originally designed to do.
But of course, this has the problem of not allowing simple tweaks, as you mentioned, which could have no unintended side effects, but fix a given problem.
As usual, trade-offs 🙂.