The examples that I have come across for when “new” makes sense involve maintenance situations where the sub class is inheriting from a base class in a library, and a new version of the library adds a method with the same name as one that has been implemented in the sub class. (See: Brittle Base Classes)
What I am wondering is if there are instances where the use of “new” is a good design choice (rather than something that can become necessary in maintenance). One thing that can’t be done with override is changing the return type of a method/property while keeping the name the same, but I question whether it’s ever a good design choice.
public class FruitBasket {
public int Weight { get; set;}
public List<Fruit> Fruits {get; set;}
}
public class AppleBasket : FruitBasket {
public new List<Apple> Fruits {get; set;}
}
One situation I know of is that you have to use new in .Net WinForms if you are databinding to an interface that inherits from another interface, and you want to bind to members in the base interface.
For example if you have
and you databind a control to a ITwo object, then you won’t be able to see the ID or Code properties unless you add them to the ITwo interface. Of course you don’t have to use new, but it is recommended.
Other than that, I have only ever used it in maintenance mode, i.e. once an app has shipped and new requirements necessitate such a change.
HTH,
Dean.