Thanks for the reply Barry. >They require two, independent, sets of semantics: one for callers > and another for implementers.
What do you mean by this? > Inheritance is probably the closest coupling that can be > created between two classes, and we all know why coupling is > bad when designing robust, modular systems. Virtual methods > make coupling even closer, because one class replaces methods > in the other. First, don't get me wrong. I think inheritance should be kept to a minimum. It's too easy to abuse and not needed nearly as much as it's actually used. However, if you are inheriting, the main reason I see for it is to alter the behavior of the parent class. If you agree with that, doesn't it stand to reason that you want to make that relative painless? I agree that perf of non-virtual method invocations would be faster (no v-table lookups, etc.). But, in my experience doing something for perf reasons only is usually a cop-out. Am I missing something? ______________________________ - David Lanouette - [EMAIL PROTECTED] "Excellence, then, is not an act, but a habit" - Aristotle > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Barry Kelly > Sent: Friday, July 07, 2006 7:53 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was > Implementing an Interface - C# vs. VB.NET > > David Lanouette <[EMAIL PROTECTED]> wrote: > > > Anybody know why methods aren't virtual by default in .NET? > It seems > > like a really bad default to have all methods non-virtual. > > If you consider the design and maintenance implications, it's > actually an incredibly bad idea to have methods default to > virtual. It's a great feature-point for C# that it didn't > follow Java's example in this area, IMO. > > Virtual methods are quite difficult to design properly. They > require two, independent, sets of semantics: one for callers > and another for implementers. Designing a class to be robust > and secure in the face of malicious or naive overriding - > something which essentially introduces external code in the > middle of the class's implementation - is not trivial. > > Inheritance is probably the closest coupling that can be > created between two classes, and we all know why coupling is > bad when designing robust, modular systems. Virtual methods > make coupling even closer, because one class replaces methods > in the other. > > It's harder to change the implementation of a class which has > lots of virtual methods, because descendants are more closely > coupled to the ancestor. That's where the maintenance and > versioning problems come in. > > This is quite independent of the performance implications, of > course, which are themselves not irrelevant: the performance > of managed code has historically been one of its most > significant weaknesses. > > I believe virtual methods should be kept to a minimum and > only introduced when necessary. > > -- Barry > > -- > http://barrkel.blogspot.com/ > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
