Is method hiding ever a good idea

Question

In C# the new modifier can be used to hide a base class method without overriding the base class method.

I've never encountered a situation where hiding a method was the best choice available. Are there any situations where method hiding is the best choice?

Answer 1

There are rare, but very good, reasons to use method hiding. Eric Lippert posted a great example on his blog:

interface IEnumerable<T> : IEnumerable { 
  new IEnumerator<T> GetEnumerator(); 
}

However, I think hiding should be the exception, and only used sparingly.

Answer 2

Yes, if you are, for example, just a consumer of a base class and a new version of base class is published that all of a sudden has the method with the exact same signature as one of the methods that you already implemented in your derived class, you need to be able to hide the base class method and you use new to make it clear that you are hiding the base class method...

Answer 3

It's often a good choice when you're creating custom controls, and want to prevent certain properties from appearing in the designer. Sometimes the properties aren't overridable, but the designer doesn't care about that, it only cares whether or not the lowest-level public property has the [Browsable] attribute.

For example, let's say that your control doesn't support padding. The Control.Padding property isn't overridable. But you also know that nothing bad is going to happen if somebody sets the padding, it's just that the property doesn't do anything, so you don't want your users to see it in the designer and think that it actually works. So, hide it:

public class MyControl : Control
{
    [Browsable(false)]
    public new Padding Padding
    {
        get { return base.Padding; }
        set { base.Padding = value; }
    }
}

In this case, we're literally using member hiding to hide the member - from the designer.

As an aside, I'm aware that there are other means of achieving this goal - this is just one possible option.

Answer 4

I tend to use it sometimes for convenience for callers, something like:

abstract public class Animal { }

public class Mouse : Animal { }



public class AnimalTrap
{
    public Animal TrappedAnimal { get; }
}

public class MouseTrap : AnimalTrap
{
    new public Mouse TrappedAnimal
    {
        get { return (Mouse)base.TrappedAnimal; }
    }
}

So the caller doesn't have to cast to Mouse themselves when the derived class guarantees the trapped animal will always be a mouse. And polymorphic functionality stays intact.

Answer 5

The most common example I can think of here is things like DbCommand vs SqlCommand; the concrete types (SqlCommand etc) generally do a lot of method hiding to make the return types of properties / methods display the correct implementation type. This is because the related objects themselves have additional (implementation-specific) features, and the caller doesn't want to have to cast every time they call do anything.