Valid applications of member hiding with the new keyword in c#

Question

I\'ve been using c# since version 1, and have never seen a worthwhile use of member hiding. Do you know of any?

Answer 1

Sometimes I make a class derived from something in the base class library, where the base class (for performance reasons) did not use a virtual function. In that case it makes sense to use 'new'. Here's one example (which matches what Marc Gravell was talking about), a strongly typed WeakReference:

public class WeakReference<T> : System.WeakReference
{
    public WeakReference(T target) : base(target) { }
    public WeakReference(T target, bool trackResurrection) : base(target, trackResurrection) { }
    #if !WindowsCE
    protected WeakReference(SerializationInfo info, StreamingContext context) : base(info, context) {}
    #endif
    public new T Target
    {
        get { return (T)base.Target; }
        set { base.Target = value; }
    }
}

In cases where the base class method actually IS virtual, I think Microsoft was envisioning cases where the base class is implemented by one party and the derived class is implemented by a second party. The second party adds a function "Foo", then later the first party adds another function "Foo" that actually does something different (so overriding would not be appropriate). Then, in order to maintain compatibility with third party code, the second party keeps their function named "Foo" despite the fact that it is not directly related to the base class version. In that case, the second party adds "new" to their declaration.

Answer 2

Making the return type more explicit - for example SqlConnection.CreateCommand returns a SqlCommand, not a DbCommand. Actually, it looks like this isn't declared new, but that would be one of the few times I would use this; most times it is evil.

Another use: remove inherited attributes from a member.

Answer 3

We had a class that inherited from the WebControl class. When we upgraded from 3.5 to 4.0, the way that some of our attributes (mainly around onclick and javascript) changed quite radically.

We could not change how the AttributeCollection class was handled by the WebControl, so what we did was implement the same methods and properties of the AttributeCollection in our custom collection and hid the AttributeCollection property with our own.

None of the accessing code changed, and we were able to correctly implement how to handle the attributes in our classes. Now no one needs to know what we did to fix the problem. All they need to know is that they call Attributes.Add like normal, and we fix things under the hood.

Answer 4

1. When a new version of a Type implements a publicly-visible member whose name conflicts with a name you've used in a derived Type.

2. To hide an inappropriate implementation in a base class from which you derive.

   For example KeyedCollection<TKey, TItem>.Contains(TItem item) is inherited from Collection<TItem> and is therefore an O(n) operation rather than the O(1) operation that KeyedCollection<TKey, TItem>.Contains(TKey key) usually provides.

   This is arguably confusing as naive consumers may think the two are interchangeable.

   So it may be appropriate to implement a "better" version:

   public new bool Contains(TItem item)
   {
       if (item == null) throw new ArgumentNullException("item");
   
       return this.Contains(GetKeyForItem(item));
   }
   

Answer 5

When making controls with rich design-time experiences, it's frequently necessary to shadow existing properties to apply attributes.

Answer 6

Generally it's considered bad practice to reject an inherited member. The only time I've used it is in generated code where the new member provided a more specific type in the same class hierarchy. Same goes for explicit interface implementations.