C# – Practical Uses of the ‘New’ Modifier for Hiding

ckeywords

A co-worker and I were looking at the behavior of the new keyword in C# as it applies to the concept of hiding. From the documentation:

Use the new modifier to explicitly hide a member inherited from a base
class. To hide an inherited member, declare it in the derived class
using the same name, and modify it with the new modifier.

We've read the documentation, and we understand what it basically does and how it does it. What we couldn't really get a handle on is why you would need to do it in the first place. The modifier has been there since 2003, and we've both been working with .Net for longer than that and it's never come up.

When would this behavior be necessary in a practical sense (e.g.: as applied to a business case)? Is this a feature that has outlived its usefulness or is what it does simply uncommon enough in what we do (specifically we do web forms and MVC applications and some small factor WinForms and WPF)? In trying this keyword out and playing with it we found some behaviors that it allows that seem a little hazardous if misused.

This sounds a little open-ended, but we're looking for a specific use case that can be applied to a business application that finds this particular tool useful.

Best Answer

You can use it to imitate return type covariance (Note: After this answer was written, C# 9.0 added support for return type covariance). Eric Lippert's Explanation . Eric provides this example code:

abstract class Enclosure
{
    protected abstract Animal GetContents();
    public Animal Contents() { return this.GetContents(); }
}
class Aquarium : Enclosure
{
    public new Fish Contents() { ... }
    protected override Animal GetContents() { return this.Contents(); }
}

This is a work-around. public override Fish Contents() { ... } is not legal, despite being safe.

In general, you should not use method hiding, as it is confusing to consumers of your class (the specific example above does not suffer from this problem). Just name your new method something else if you don't want to override an existing method.

A likely real-world situation where you would need method hiding is if the provider of a base class added a generic method which you had already added to a derived class. Such a program will compile (and give warnings) without the new keyword, but adding new says, "I know my version of this method is replacing the base class's version. This is horrible and confusing, but we're stuck with it." That's still better than forcing the derived class to rename their method.

Just allowing the derived method to be treated as being an override would cause problems. Ignoring any concerns with implementing the compiler, the new method is semantically different from the base method, but polymorphism would cause the new method to be called when asked to call a method with the same name.

This situation is discussed in detail in this post by Eric Lippert.

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

[1] Add virtual "getters" & "setters" to your properties, I had to hack another control library, because I need this feature:

abstract class Control
{
    // internal fields for properties
    protected int _Width;
    protected int _Height;
    protected int _BackColor;
    protected int _X;
    protected int _Y;
    protected bool Visible;

    protected int BorderWidth;
    protected int BorderColor;


    // getters & setters virtual !!!

    public virtual int getWidth(...) { ... }
    public virtual void setWidth(...) { ... }

    public virtual int getHeight(...) { ... }
    public virtual void setHeight(...) { ... }

    public virtual int getBackColor(...) { ... }
    public virtual void setBackColor(...) { ... }

    public virtual int getX(...) { ... }
    public virtual void setX(...) { ... }

    public virtual int getY(...) { ... }
    public virtual void setY(...) { ... }

    public virtual int getBorderWidth(...) { ... }
    public virtual void setBorderWidth(...) { ... }

    public virtual int getBorderColor(...) { ... }
    public virtual void setBorderColor(...) { ... }

    public virtual bool getVisible(...) { ... }
    public virtual void setVisible(...) { ... }

    // properties WITH virtual getters & setters

    public int Width { get getWidth(); set setWidth(value); }

    public int Height { get getHeight(); set setHeight(value); }

    public int BackColor { get getBackColor(); set setBackColor(value); }

    public int X { get getX(); set setX(value); }

    public int Y { get getY(); set setY(value); }

    public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }

    public int BorderColor { get getBorderColor(); set setBorderColor(value); }

    public bool Visible { get getVisible(); set setVisible(value); }

    // other methods

    public Rectangle ClipRectange { get; protected set; }   
    abstract public void Draw();
} // class Control

/* concrete */ class MyControl: Control
{
    public override bool getVisible(...) { ... }
    public override void setVisible(...) { ... }
} // class MyControl: Control

I know this suggestion is more "verbose" or complex, but, its very useful in real world.

[2] Add an "IsEnabled" property, do not confuse with "IsReadOnly":

abstract class Control
{
    // internal fields for properties
    protected bool _IsEnabled;

    public virtual bool getIsEnabled(...) { ... }
    public virtual void setIsEnabled(...) { ... }

    public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control

Means you may have to show your control, but don't show any information.

[3] Add a "IsReadOnly" property, do not confuse with "IsEnabled":

abstract class Control
{
    // internal fields for properties
    protected bool _IsReadOnly;

    public virtual bool getIsReadOnly(...) { ... }
    public virtual void setIsReadOnly(...) { ... }

    public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control

That means the control can display information, but cannot be changed by the user.

C# – Why Shouldn’t an Object Reference Access a Static Member?

Nothing go wrong for accessing a static member from an instance, in fact this is perfectly possible in other languages like java, your example code compiles and runs ok if its in java.

It's a check the compiler designers have introduced because they thought that this will help programmers to write clear code with this language. On this way only looking at the code you can always know if you are accessing a static or an instance member, in languages where this access is allow (like java) sometimes its a little confusing when someone decides to access a static member throughout an instance variable, in fact normally when you see this access in java code its more a mistake than a programmer really using this "language feature".

In my opinion limiting this access its a good decision in C# to avoid some mistakes and bad interpretations.

Although it's legal in Java to refer static members that way, it's recommended against in Code Conventions (10.2 Referring to Class Variables and Methods):

"Avoid using an object to access a class (static) variable or method. Use a class name instead..."

Best Answer

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

C# – Why Shouldn’t an Object Reference Access a Static Member?

Related Topic