This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: More on virtual by default
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
Gary and James took issue with my position, so I'd like to expand a bit on what I said.
Gary wrote:
Eric suggests that final should be used in most cases with virtual reserved for the special occasions. I totally disagree, you can't lay down the law as to how another developer is going to extend your class, (other than in the special circumstances I mention here). If the choice is being flexible versus being static, then in the interests of good software engineering you *must* go with the flexible option. Or is that just the Smalltalk programmer in me coming out :)
My answer to that question would be “yes”. I'm not being flippant on that, and I'm about as far from being a Smalltalk programmer as you can be, but I think it comes down to the tradeoff between robustness and flexibility. If you allow more extensibility, you are being more flexible, and also being less robust (or, to be precise, being potentially less robust), especially if you aren't testing the extensibility.
James wrote:
The long and short of it - Eric thinks that library designers know everything and that one of the primary jobs is to protect those dumb application developers. There's just no telling what they might do if we let them.
James has it backwards. I don't think that library designers know everything. I think that they know very little about how users might use their classes, and therefore shouldn't be making promises their code can't keep. If they want to support extensibility, then that should be something they design well and test for. If they aren't going to go to that effort, than I don't think providing extensibility that will “probably work” is doing their users a service, and it may be actively doing them a disservice. Not only will such code be more likely to fail, but the constraint of such virtuals limits how the class can evolve in the future. It's bad when you'd like to make a small change that would help 99.9% of your users, but you can't because somebody might have existing code that depends on your behavior. But maybe that's just the compiler guy in me...
I do think that this depends on the kind of library you're building. In general, the more closely coupled the api writer and user ae, theless of an issue this is.
Previous Topic
