Why are methods virtual by default in Java, but non-virtual by default in C#? [closed]

Answer 1

.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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

There are 2 major reasons why virtual by default is so much better than non-virtual.

1. The main principles about usefulness of OOP is Liskov substitution principle, polymorphism and late binding . I use strategy pattern all the time and for that I want my methods to be virtual. If you are fan of Open/closed principle you should like Java philosophy more. You should be able to change behavior without changing your source code. You can do that with dependency injection and virtual methods.
2. If you call a non-virtual method then you want to know from your code which class method you are calling. The flaw of .net is that you cannot know that from your code.
3. Another benefit of virtual-only method is that it is much easier to test your code because you can make Mocks of your (or 3rd party) classes. Testing with Mockito is really easy in Java.

Example

In Java if you define ClassB as

public class ClassB extends ClassA {
    @Override 
    public void run() {
    }
}

and object

ClassA obj=new ClassB();

If you call obj.run() how will you know if that code is following the rules of polymorphic open/close principle or it will code method related to ClassA? In Java you will know that there is always polymorphism. It is easier to make mocks and it is easier to extend classes and follow Liskov substitution principle.

On the other hand static methods are bounded to a class so if you want to call a method that is related to ClassA you can define that method like this:

public static run(ClassA obj)

and you can call it with

ClassB obj=new ClassB();
ClassA.run(obj);

and from the code you will know that the method you are calling is defined in ClassA and not in ClassB. Also in that case you will not have the overhead of virtual methods. (Note that JIT will also reduce the overhead of virtual methods in many cases).

For C#, if the reason to make the method non-virtual is to be able to define it in a subclass but not involve polymorphism, you're probably subclassing for no real reason.

If it's for design, I'd suggest making the class sealed (final in java) instead of individual methods if possible.

Jon Skeet said that in C# the classes should be sealed by default because methods are non-virtual by default as well. Joshua Bloch said that you should design for inheritance or forbid it (make classes final). C# designers chose a hybrid approach which is non-consistent.

Answer 6

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.