tags:

views:

291

answers:

6

Hi,

Why java functions are virtual by default.But c# its the oposite.

Which is better?Or what is the advantage and disadvantage in both?

Thanks

SC

+18  A: 

Anders Hejlsberg: (C# lead architect)

There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.

A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual."

When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant.

Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.

arul
Good interview question if I see somone with both Java and .Net in the Resume :) +1
Perpetualcoder
+1  A: 

Anders Hejlsberg's answer: http://www.artima.com/intv/nonvirtual.html

jerryjvl
+2  A: 

Java's way is simpler, C#'s way is more granular, safer and more efficient by default. Which is better is in the eye of the beer holder.

Gerald
I would argue quite the opposite. Java's is more complex because it has a hidden cost. Virtual methods are not free in both speed and design cost.
JaredPar
So do you consider assembly language to be the least complex language to sue?
Gerald
use* (silly character minimum)
Gerald
@Gerald, that's a false analogy. You're comparing a high level languages to assembly. I consider virtual methods harder to maintain because you must have a greater understanding of the object hierarchy in order to understand how a method fits into the system. So I consider C# a simpler language to maintain than Java in general because the defaults of the defaults of the language favor maintainability. Just like I favor F# over C# in maintenance because it goes even further in that area with immutable by default.
JaredPar
@Jared, it was an intentional false analogy in response to your false correlation between hidden costs and complexity. Simpler things almost always have hidden costs. I think it should have been obvious that I was referring to the simplicity of it's usage, not it's maintainability, especially since I made a point of stating that C# was safer. For the record I prefer C# as well, but it's pretty hard to deny that not having to declare something to use it is simpler than having to declare something to use it.
Gerald
@Gerald, Why do you think hidden costs is not correlated to complexity? I would argue they are strongly correlated especially when you consider the maintenance angle. But yes, having everything be virtual is simpler in that you don't have to think, you just do.
JaredPar
@Jared, I suppose in the case of maintainability of code with an over-abundance of virtual methods, a case can be made that they're not completely uncorrelated. But it would only be marginally so. Since 9 times out of 10 a method that isn't made virtual to start is perfectly fine to override, the solution is often just to go make it virtual if you need to override it. Maybe you'll look at the code to see if there is a reason it shouldn't be, but you may not know as well as the original author. While if a method is specifically marked as final, it may make you think harder about changing it.
Gerald
A: 

.Net forces the programmer to define which functions may be overriden, whereas Java functions, by default, can be overriden unless the final keyword is used.

If you're a strong advocate of the Open/Close Principle you may tend to support the Java way. It's best to allow classes to be extended and methods to be overriden such that the base functionality/code is untouched. For this reason, I support/prefer the Java way. If I were looking at the question from a different perspective, my opinion may be the opposite.

Elliot
A: 

It's a perturbation in time. C++ uses the virtual keyword and final as default.

Java follows C++ and attempts to take the best and improve on its shortcomings. The dangers of overuse of inheritance haven't come to light, so Java chooses to use the final keyword and virtual as default.

C# follows Java and has the benefit of hindsight. Anders chooses to go back to the C++ convention after observing Java's experience.

duffymo
+1  A: 

As always, there are pros and cons. C# has made AOP more difficult to implement, but hindsight can be 20/20 as mentioned by others. It all boils down to whether or not you believe that classes must be designed for extension or simply left open for unforeseen behavior modifications. When designing a language, this is a tough question to answer. I think industry experience is leaning towards the more conservative approach that C# takes.

Todd Stout