class BaseClass
{
public Model TheModel { get; set; }
}

DerivedClass instance = new DerivedClass() { TheModel = new DerivedModel }; // fine
((BaseClass)instance).TheModel = new IncompatibleModel(); // will pass because IncompatibleModel inherits from Model, but trouble is brewing
Console.WriteLine(instance.TheModel); // typecast failure in the getter


But I control for that in code, so I feel safe using it.

I’ve also used it in slightly less safe context to convert the value of CheckBox.Checked to Nullable. (If Checked = null is set, we set the display to render the indeterminate checked state, and set “false” to the underlying Checked property). So long as I always reference Checked by a derived class reference or through reflection (e.g., data binding), everything’s fine, but I feel less sanguine about this solution.

Specifically, a base class provided a method returning ISomeType. An inheriting class always provided an ISomeOtherType (where ISomeOtherType inherits from ISomeType). If a reference to the inheriting class was used, I used the new keyword to ensure that when the method was called a reference to an ISomeOtherType was used. This meant it was not necessary for any caller to know that the value returned could be cast to ISomeOtherType.

@Davy My most common use case for “new” is on interfaces, where I want to have both a generic and non-generic version. But “new” on interfaces (where an implementing class is required to provide both versions) doesn’t often lead to the kind of bugs you’re describing.

well, once you pass instances of your derived Combobox to code that requires a Combobox reference and accesses one of those methods, you’ll run into the issues i mentioned.

Composition solves most of the problems with concrete class inheritance, because it makes everything explicit. If you implement an interface and provide a base implementation for that interface, all methods in the interface must be explicitly dealt with.

i would prefer virtual-by-default but i do understand their decision to make non-virtual the default.

Just today morning, I discussed virtual vs non-virtual with my team and here I read your entry. Passed this to my team and they have enjoyed it very much.

good point


public class BaseSomething
{
public object Model { get; set; }
}

public class BaseSomething
{
public new TModel Model
{
get { return (TModel)base.Model; }
set { base.Model = value; }
}
}


It should not break anyting, but it provides an extra useful generic layer.

For an explanation and a few reasonable use cases, see this post on Eric Lippert’s blog.