What is virtual/override for?

Question

.NET

Recently I went to an interview for the position of a .Net developer, at the interview I was asked "What is virtual / override for?". I talked about the fact that by marking a method virtual, we can override it in the heir class and either add our own implementation to the base one, or leave only our own. Next I was asked "just so that you can override the method?", I said that in EF for lazy loading of data, in the end my answers were not an exhaustive answer to the question.
What other answers might there be?
PS I did not ask the interviewer for the correct answer, as there were doubts about his professionalism

Answer 1

Akhtung, comrade. Before you doubt the professionalism of your colleagues, I strongly advise you to at least a little doubt your own. This is at least occasionally useful. And now, legs in hand and go ahead to read about tables, virtuality and methods . This is not only useful, but archival. Considering the question.
And the question was the following. Here we have objects, inherited from each other, implemented and everything is cool, fine, but bldjad. Why are they needed? No, not data aggregation, although it is, too. No, not implementation aggregation, although it is, too. And no, no, not just because. Although this is also ... But think about this situation. There is a library. Yes, it doesn’t matter which one, well, let it be UI / UX. Here is an abstract (!) button class. Why abstract? Yes, because any button is a button. It's like a class on top of a class. The button can be red, it can be clickable, it can become unclickable after being pressed, it can open a file selection dialog, or it can close the damn application. In general, a button can do a lot of things. And I want to put this button on the form. And the creator of the library made such a wonderful method for the form PutAnyButtonHere(Button btn, Point xy). But... Damn, dude, we have to pass an object of the Button class, and we have some kind of MyBestButton : BestAbstractLibraryButton , which is the same Button. And Button has such a wonderful method TimeWhenUserClickOnMe(Point xy, AnotherInfo somethinElse), in fact... It turns out that somewhere in the bowels of that very library, when the author of a wonderful UI / UX library calls this very method, he must call OUR implementation, and not an implementation of BestAbstractLibraryButton. And certainly not a non-existent Button implementation (because the method is purely virtual there). The idea of ​​virtual methods initially is that there is a special table that stores implementations separately, objects separately,
And the keywords are just so that the programmer, reading other people's canvases of code, at least a little, has the opportunity to somehow understand them. What exactly did the programmer want in a particular situation. And, if in Java all methods are virtual by default and it’s not clear from other people’s canvases, the programmer wanted late binding here, or is it just an aggregation of functionality, then in the sharp this problem is “as if not”, the language is sometimes extremely verbose on, it seemed, such platitudes. Which in the end is rare, but saves a hell of a cloud of time.
Dry residue. If we call a virtual method on a class object of a successor of some super-class having a super-class type reference, then the implementation of the successor's method is called. If we call a non-virtual method on a class object of a descendant of some super-class having a super-class type reference, then the implementation of the super-class method is called. The rest of the behavior is trivial.
Gag. Without understanding these things, it is impossible to say that the principles of object-oriented programming have been mastered. I advise you to read "Philosophy of Java" (in general, there Java is more like a language for examples, in general, OOP is also in OOP Africa). Well, try to understand the point of view of any person, especially if his competence is at least something confirmed (for example, successful employment).

Answer 2

"I did not ask the interviewer for the correct answer, as there were doubts about his professionalism" - this is strong.
We can override without virtual methods.
And they come in handy when you have a reference to a base class that leads to an inherited one. Then, when you try to call a non-virtual method, the base class method will be called. If it is virtual, then the method is inherited.

Answer 3

Ваша ответ, как ни странно, не является исчерпывающим.
virtual/override нужен для того, чтоб менять метод на протяжении всей цепочки классов.
Пример.
У нас есть класс A с виртуальной функцией. Мы создали из него класс B и преопределили там эту функцию. Потом мы создали objA класса A и objB класса B. Потом мы присвоили objA objB и вызвали эту функцию из objA. Вызовется реализация класса B, а не A. А при обычном замещении было бы наоборот. Вот в чем прикол!