What is the purpose of hiding (using the "new" modifier) an interface method declaration?

it's possible to mark a method declaration in an interface as "new" but does it开发者_运维知识库 have any "technical" sense or is it just a way to explicitly state that the declaration cannot override a previous one ?

For example :

interface II1
{
    new void F();
}

interface II2 : II1
{
    new void F();
}

is valid (the C# 4.0 compiler does not complain) but does not appear to be different from :

interface II1
{
    void F();
}

interface II2 : II1
{
    void F();
}

Thanks in advance for any information.

EDIT: do you know a scenario where hiding in an interface would be useful ?

EDIT: According to this link : Is method hiding ever a good idea (thanks Scott), the most common scenario seems to be the emulation of covariant return type.

---

The second example issues the following compiler warning:

'II2.F()' hides inherited member 'II1.F()'. Use the new keyword if hiding was intended.

I'd say the difference of using the new keyword is exactly that: showing intention.

---

The two are very different. By using 'new' you are creating a new inheritance chain. This means any implementations of II2 will need to realize both versions of F(), and the actual one you end up calling will depend upon the type of the reference.

Consider the following three realizations:

    class A1 : II1
    {
        public void F()
        {
            // realizes II1.F()
        }
    }

    class A2 : II2
    {
        void II1.F()
        {
            // realizes II1.F()
        }

        void II2.F()
        {
            // realizes II2.F()
        }
    }

    class A3 : II2
    {
        public void F()
        {
            // realizes II1.F()
        }

        void II2.F()
        {
            // realizes II2.F()
        }
    }

If you have a reference to A2, you will not be able to call either version of F() without first casting to II1 or II2.

A2 a2 = new A2();
a2.F(); // invalid as both are explicitly implemented
((II1) a2).F(); // calls the II1 implementation
((II2) a2).F(); // calls the II2 implementation

If you have a reference to A3, you will be able to call the II1 version directly as it is an implicit implentation:

A3 a3 = new A3();
a3.F(); // calls the II1 implementation
((II2) a3).F(); // calls the II2 implementation

---

I know of one good use for this: you have to do this to declare a COM interface that's derived from another COM interface. It is touched upon in this magazine article.

Fwiw, the author completely misidentifies the source of the problem, it has nothing to do with an 'inheritance tax'. COM simply leverages the way a typical C++ compiler implements multiple inheritance. There's one v-table for each base class, just what COM needs. The CLR doesn't do this, it doesn't support MI and there's only ever one v-table. Interface methods are merged into the v-table of the base class.

---

An example following Fredrik's answer. I want to have an interface that represents a method to get an entity by id. I then want both a WCF service and some other standard repository able to be used as that interface. In order to play with WCF, I need to decorate my interface with attributes. From an intent standpoint, I don't want to decorate my interface with WCF stuff when it's not going to be used via only WCF, so I need to use new. Here's the code:

public class Dog
{
    public int Id { get; set; }
}

public interface IGetById<TEntity>
{
    TEntity GetById(int id);
}

public interface IDogRepository : IGetById<Dog> { }

public class DogRepository : IDogRepository
{
    public Dog GetById(int id)
    {
        throw new NotImplementedException();
    }
}

[ServiceContract]
public interface IWcfService : IGetById<Dog>
{
    [OperationContract(Name="GetDogById")]
    new Dog GetById(int id);
}

---

The new modifier is very simple, it just suppresses the compiler warning that is created when a method is hidden. If used on a method that does not hide another method a warning is generated.

From The C# Language Specification 3.0

10.3.4 The new modifier A class-member-declaration is permitted to declare a member with the same name or signature as an inherited member. When this occurs, the derived class member is said to hide the base class member. Hiding an inherited member is not considered an error, but it does cause the compiler to issue a warning. To suppress the warning, the declaration of the derived class member can include a new modifier to indicate that the derived member is intended to hide the base member. This topic is discussed further in §3.7.1.2. If a new modifier is included in a declaration that doesn’t hide an inherited member, a warning to that effect is issued. This warning is suppressed by removing the new modifier.

---

Having read through these answers, they explain pretty well what the new operator does, but I don't see any clear answer to this part of the OP's question:

do you know a scenario where hiding in an interface would be useful ?

In summary, it all boils down to testability and reuse. By splitting up interfaces into smaller chunks, and adhering to the Interface Separation Principle, we can make users of our classes minimally dependent on irrelevant detail and maximally decoupled, which provides us with more reusability options and an easier time when it comes to testing.

In general, the new operator comes into play here when we need to branch our interface type-hierarchy in a way where method collisions are unavoidable. That all sounds a bit abstract and it's hard to explain, so I created what I believe is a minimal example where we want to split our interface type hierarchy into two, while there's a common shared method. I put the code on .NET fiddle:

https://dotnetfiddle.net/kRQpoU

Here it is again:

using System;

public class Program
{
    public static void Main()
    {
        //Simple usage
        var simpleCuboid = new MockCuboidSimple();
        var heightUser = new HeightUserEntangled();
        var volumeUser = new VolumeUserEntangled();
        Console.WriteLine("*** Simple Case ***");
        Console.WriteLine(heightUser.PrintHeight(simpleCuboid));
        Console.WriteLine(volumeUser.PrintVolume(simpleCuboid));

        //Smart usage - the same behaviour, but more testable behind the scenes!
        var smartCuboid = new MockCuboidSmart();
        var heightUserSmart = new HeightUserSmart();
        var volumeUserSmart = new VolumeUserSmart();
        Console.WriteLine("*** smart Case ***");
        Console.WriteLine(heightUserSmart.PrintHeight(smartCuboid));
        Console.WriteLine(volumeUserSmart.PrintVolume(smartCuboid));
    }
}

//Disentangled

class VolumeUserSmart
{
    public string PrintVolume(IThingWithVolume volumeThing)
    {
        return string.Format("Object {0} has volume {1}", volumeThing.Name, volumeThing.Volume);
    }       
}

class HeightUserSmart
{
    public string PrintHeight(IThingWithHeight heightThing)
    {
        return string.Format("Object {0} has height {1}", heightThing.Name, heightThing.Height);
    }       
}

class MockCuboidSmart : ICuboidSmart
{
    public string Name => "Mrs. Cuboid";
    public double Height => 3.333;
    public double Width => 31.23432;
    public double Length => 123.12;
    public double Volume => Height * Width * Length;
}

interface ICuboidSmart : IThingWithHeight, IThingWithVolume
{
    //Here's where we use new, to be explicit about our intentions
    new string Name {get;}
    double Width {get;}
    double Length {get;}
    //Potentially more methods here using external types over which we have no control - hard to mock up for testing
}

interface IThingWithHeight
{
    string Name {get;}
    double Height {get;}
}   

interface IThingWithVolume
{
    string Name {get;}
    double Volume {get;}
}

//Entangled

class VolumeUserEntangled
{
    public string PrintVolume(ICuboidSimple cuboid)
    {
        return string.Format("Object {0} has volume {1}", cuboid.Name, cuboid.Volume);
    }       
}

class HeightUserEntangled
{
    public string PrintHeight(ICuboidSimple cuboid)
    {
        return string.Format("Object {0} has height {1}", cuboid.Name, cuboid.Height);
    }       
}

class MockCuboidSimple : ICuboidSimple
{
    public string Name => "Mrs. Cuboid";
    public double Height => 3.333;
    public double Width => 31.23432;
    public double Length => 123.12;
    public double Volume => Height * Width * Length;
}

interface ICuboidSimple
{
    string Name {get;}
    double Height {get;}
    double Width {get;}
    double Length {get;}
    double Volume {get;}
    //Potentially more methods here using external types over which we have no control - hard to mock up for testing
}

Notice that VolumeUserSmart and HeightUserSmart only depend on fragments of the ICuboidSmart interface that they care about, namely IThingWithHeight and IThingWithVolume. This way, they can be maximally reused, e.g. for shapes other than cuboids, and also can be more easily tested. The last point is, I find in practice, crucial. It's much easier to mock up an interface with fewer methods, especially if the methods in the main interface type contain references to types that we don't control. Of course, one can always get around this with a mocking framework, but I prefer to keep the code clean at its core.

So where does the new keyword fit in here? Well, since VolumeUserSmart and HeightUserSmart both need access to the Name property, we must must declare it in both IThingWithHeight and IThingWithVolume. And thus we must redeclare it in the sub-interface ICuboidSmart, or else we'll get a compiler error complaining about ambiguity. What we're doing in that case is hiding the two versions of Name defined in IThingWithHeight and IThingWithVolume that would otherwise collide. And, like other answers point out, though we don't have to use new here, we should, to be explicit about our intentions to hide.

---

I use it almost in every my interface. Look here:

interface ICreature
{
    /// <summary>
    ///     Creature's age
    /// </summary>
    /// <returns>
    ///     From 0 to int.Max
    /// </returns>
    int GetAge();
}

interface IHuman : ICreature
{
    /// <summary>
    ///     Human's age
    /// </summary>
    /// <returns>
    ///     From 0 to 999
    /// </returns>
    new int GetAge();
}

It is absolutely normal to have an inherited member with lesser requirements but larger obligations. LSP is not violated. But if so, where to document the new contract?