As part of the WinFX review team, I regularly review APIs for usability issues. One thing that we as a team have been highlighting as a potential issue is the use of virtual properties. Consider the following code snippet:

public class Class1
{
    private string theString;

    public virtual string MyString
    {
        get{return theString;}
        set{theString = value;}
    }
}

public class Class2 : Class1
{
   
public override string MyString
   
{
       
get{return "Ha ha!";}
       
set{base.MyString = value;}
   
}
}

Code that accesses the MyString property of an instance of Class1 might either return the actual string or “Ha ha!” depending on the actual runtime type.

The design guidelines suggest that properties should not be used if they perform some expensive operation (see Brad's post on a similar issue). Calling a virtual property or method is more expensive than calling non-virtual methods or properties so that is one reason for not creating virtual properties. Another reason is that we believe the code to access a property doesn't really suggest that the value of MyString depends on the runtime type of the object. Consider the following:

public void DoSomething(Class1 c1){Console.WriteLine(c1.MyString);}

In this case, a developer might be surprised if calling DoSomething resulted in “Ha ha!“ being output to the console. We believe that to provide a consistent user experience, properties should mimic simple field access as much as possible. Thus virtual properties run the risk of breaking this consistency since in some cases, some properties work just like accessing a field while in other cases they work more like a virtual method call.

We're not suggesting that there is never a good reason for declaring virtual properties. We're just discouraging the use of virtual properties and encouraging the use of virtual methods instead.

However, I'd be interested in your feedback on this issue. Are we being too cautious?