In Java you can mark method as final to make it impossible to override.
In C# you have to mark method as virtual to make it possible to override.
Does it mean that in C# you should mark all methods virtual (except a few ones that you don't want to be overridden), since most likely you don't know in what way your class can be inherited?
In C# you have to mark method as virtual to make it possible to override. Does it mean that in C# you should mark all methods virtual (except a few ones that you don't want to be overridden), since most likely you don't know in what way your class can be inherited?
No. If the language designers thought that virtual should have been the default then it would have been the default.
Overridablility is a feature, and like all features it has costs. The costs of an overrideable method are considerable: there are big design, implementation and testing costs, particularly if there is any "sensitivity" to the class; virtual methods are ways of introducing untested third-party code into a system and that has a security impact.
If you don't know how you intend your class to be inherited then don't publish your class because you haven't finished designing it yet. Your extensibility model is definitely something you should know ahead of time; it should deeply influence your design and testing strategy.
I advocate that all classes be sealed and all methods be non-virtual until you have a real-world customer-focussed reason to unseal or to make a method virtual.
Basically your question is "I am ignorant of how my customers intend to consume my class; should I therefore make it arbitrarily extensible?" No; you should become knowledgable! You wouldn't ask "I don't know how my customers are going to use my class, so should I make all my properties read-write? And should I make all my methods read-write properties of delegate type so that my users can replace any method with their own implementation?" No, don't do any of those things until you have evidence that a user actually needs that capability! Spend your valuable time designing, testing and implementing features that users actually want and need, and do so from a position of knowledge.
sealed by default, which they are not. –
Lashio SerialPort restricts supported Encodings to those definied in mscorlib.dll)). –
Marlinmarline System.Web’s sorry state is due to the fact that the classes are sealed, and that not having them sealed (and not changing anything else) would solve all those problems. That’s simply a baseless assertion, and as such, can be rejected. Other web framework pursue fundamentally different approaches. (Note, again, that I’m not talking about interfaces here at all.) –
Madriene non-virtual (and sealed) by default is justified (given most alt langs don't enfoce it). The real problem in practice is not being able extend/override built-in/3rd-Party behavior. Like Java's checked-exceptions I think non-virtual is good in theory, but fails in practice. –
Arsenault public virtual void Foo() { Bar(); } you could write public Action Foo = () => { Bar(); }. Now if a user of the class wishes x.Foo() to call Blah() they don't need to override the class; they just say x.Foo = ()=> { Blah(); }. Virtual methods are a mechanism for customizing a class through subclassing. If customization by users is the goal then why require them to use subclassing? That's a completely unnecessary added complication. My point is that people who say to make everything virtual for maximum flexibility are hitting a point nowhere near the maximum. –
Ferritin I advocate that all classes be sealed and all methods be non-virtual until you have a real-world customer-focussed reason to unseal or to make a method virtual. Maybe in 2013 corporate development world it was true, but now it's not. And if you make a library with this approach, your "customers" will choose to write their own library, rather than use yours (or wait for months while you change something). You don't know all cases your class can be used. –
Gilmore In my opinion the currently accepted answer is unnecessarily dogmatic.
Fact is that when you don't mark a method as virtual, others cannot override its behaviour and when you mark a class as sealed others cannot inherit from the class. This can cause substantial pain. I don't know how many times I cursed an API for marking classes sealed or not marking methods virtual simply because they did not anticipate my use case.
Theoretically it might be the correct approach to only allow overriding methods and inheriting classes which are meant to be overridden and inherited but in practice it's impossible to foresee every possible scenario and there really isn't a good reason to be so closed in.
sealed. virtual.One way to make the call is to look at the name of the method or property. A GetLength() method on a List does exactly what the name implies and it doesn't allow for much of interpretation. Changing its implementation would likely be not very transparent so marking it as virtual is probably unnecessary. Marking the Add method as virtual is far more useful as someone could create a special List which only accepts some objects via the Add method etc. Another example are custom controls. You would want to make the main drawing method virtual so others can use the bulk of the behaviour and just change the look but you probably wouldn't override the X and Y properties.
In the end you often don't have to make that decision right away. In an internal project where you can easily change the code anyway I wouldn't worry about these things. If a method needs to be overridden you can always make it virtual when this happens. On the contrary, if the project is an API or library which is consumed by others and slow to update, it certainly pays off to think about which classes and methods might be useful. In this case I think it's better to be open rather than strictly closed.
JoinedList extends List that dynamically joins two lists together at the time of asking it for its content? Now the GetLength would need overriding. Just always make everything virtual. Obviously an IList interface could solve this as well, but why not both? –
Handal No! Because you don't know how your class will be inherited, you should only mark a method as virtual if you know that you want it to be overridden.
virtual is a promise to support all possible overrides of that method. That needs to be properly designed into the class. –
Hairline No. Only methods that you want derived classes to specify should be virtual.
Virtual is not related to final.
To prevent overriding of a virtual method in c# you use sealed
public class MyClass
{
public sealed override void MyFinalMethod() {...}
}
final on a method means not virtual. –
Hairline Yes you should. I wish to answer a different answer than most other answers. This is a flaw in C#. A defect. A mistake in its design. You can see that when comparing to Java where all methods are "virtual" unless, specified otherwise ("final"). Of course that if there is a class "Rectangle" with a method of "Area", and you wish to have your own class that represents a "Rectangle" with margins. You wish to take advantage of the existing class with all of its properties and methods and you just want to add a property of "margin" that adds some value to the regular rectangle area, and if the area method in Rectangle is not marked virtual, you are doomed. Image please a method that takes an array of Rectangles and returns the sum of the area of all rectangles. Some can be regular rectangles and some with margin. Now read back the answer that is marked "correct" the describe "secuirty issue" or "testing". Those are meaningless compared to the disability to override.
I am not surprised that others answered "no". I am surprised that the authors of C# couldn't see that while basing their language on Java.
We can conjure up reasons for/again either camp, but that's entirely useless.
In Java there are millions of unintended non-final public methods, but we hear very few horror stories.
In C# there are millions of sealed public methods, and we hear very few horror stories.
So it is not a big deal - the need to override a public method is rare, so it's moot either way.
This reminds me of another argument - whether a local variable should be final by default. It is a pretty good idea, but we cannot exaggerate how valuable it is. There are billions of local variables that could be, but are not, final, but it has been shown to be an actual problem.
final, whereas there are numerous complaints already under this very SO question about C# missing virtuals in its methods. –
Handal Making a method virtual will generally slow down any code that needs to call it. This slowdown will be insignificant but may in some cases be quite large (among other things, because non-virtual method calls may be in-lined, which may in turn allow the optimizer to eliminate unnecessary operations). It's not always possible to predict the extent to which virtual calls may affect execution speed, and one should generally void doing things which will make code slower except when there's a discernible benefit for doing so.
The performance benefit of making methods non-virtual is probably sufficient in many cases to justify having methods be non-virtual by default, but when classes are designed to be inherited most methods should be virtual and unsealed; the primary usage for non-virtual or sealed methods should be as wrappers for other (possibly protected) virtual methods (code that wants to change the underlying behavior should override the appropriate virtual rather than the wrapper).
There are frequently non-performance-related reasons for marking classes as sealed or limiting inheritance to other classes within the assembly. Among other things, if a class is externally inheritable, all members with protected scope are effectively added to its public API, and any changes to their behavior in the base class may break any derived classes that rely upon that behavior. On the other hand, if a class is inheritable, making its methods virtual doesn't really increase its exposure. If anything, it may reduce derived class's reliance upon the base class internals by allowing them to completely "bury" aspects of the base class implementation that are no longer relevant in the derived class [e.g. if the members of List<T> were virtual, a derived class which overrode them all could use an array of arrays to hold things (avoiding large-object-heap issues), and wouldn't have to try to keep the private array used by List<T> consistent with the array-of-arrays.
No, you should not mark all methods as virtual. You should consider how your class could be inherited. If the class should not be inherited, then mark it sealed and obviously the members should not be virtual. If your class is likely to be inherited, you really should maximize the ability to override the behavior. Therefore generously use virtual everywhere in such classes unless you have a reason not to.
© 2022 - 2024 — McMap. All rights reserved.
finalby default. – Madrienefinalfields, I know that he talks about them. But I think he also talks about final methods in Effective Java. However, I may misremember this. I’m sure though that he mentioned it elsewhere then – maybe in one of his talks. – Madrienefinal, while in reality it is not. Some are used to show that evenfinaldoesn't help immutability (notorious j.u.Date), somefinalare used as "awful candidate for default serialized form" - StringList and so on.No class in collection framework is final, either.Admittedly, I'm no great fan of his, I haven't followed his talks but unless you have a source for Java guru advocating "final methods by default" I'd not accept it. – Mythify