Renaming an interface without breaking code

Question

If I want to rename an interface without breaking existing code, would this work?

The old interface:

namespace RenameInterfaceNicely
{
    /// <summary>
    /// The old name of the interface.
    /// </summary>
    [Obsolete("IFoo is replaced by IFooNew.")]
    public interface IFoo
    {
        void Test();
    }
}

The new, renamed, interface:

namespace RenameInterfaceNicely
{
#pragma warning disable 0618
    /// <summary>
    /// IFooNew new name for the interface IFoo.
    /// </summary>
    public interface IFooNew : IFoo
    {
    }
#pragma warning restore 0618

}

So if I have a class Foo that used the old interface, that I now change to use the new interface. Will users of Foo get in trouble?

Foo before the change:

public class Foo : IFoo
{
    public void Test()
    {    
        // Do something       
        return;
    }
}

Foo after the change:

public class Foo : IFooNew
{
    public void Test()
    {    
        // Do something       
        return;
    }
}

Example of existing code:

// Old code
IFoo oldFoo = new Foo();
oldFoo.Test();
IFoo oldFoo2 = new Bar().GetFoo();

...

Bar bar = new Bar();
bar.DoSomethingWithFoo(oldFoo);

Example of new code:

// New code
IFooNew newFoo = new Foo();
newFoo.Test();
IFooNew newFoo2 = new Bar().GetFoo();

...

Bar bar = new Bar();
bar.DoSomethingWithFoo(newFoo);

My question was inspired by this one: A definitive guide to API-breaking changes in .NET and the fact that someone made a breaking change by renaming some interfaces that I was using.

Answer 1

In the case of a genuine rename: everyone will need to recompile to pick up that change. It is a dangerous change, frankly. Interfaces are contracts, and should not be renamed. If the rename is unavoidable, however, this does at least let them know what to change it to.

--

However, actually: what you have demonstrated isn't a rename; it is a semi-compulsory extension; the IFoo still exists and still has the old features. Presumably you want people to start providing IFooNew implementations. That's reasonable, but you should aim to ensure that if a consumer only implements IFoo, then it continues to work.

Answer 2

Renaming a public type or member is a breaking change.

• You don't get source compatibility. Source code that explicitly mentions the interface name, it will need to be changed.
• Depending code in the same solution can be changed automatically via rename refactoring
• You might be able to keep binary code that depends on the interface working using Type forwarding. This has been designed for moving types between assemblies not for renaming, so I'm not sure if it works.

Deriving a new interface from the old one is still breaking:

• When implementing a method explicitly, you need to refer to the type the method is on
• A class implementing the old interface won't implement the new interface.
• Code returning the old interface will still return the old interface

Answer 3

You may want to consider copying the definition from IFoo into IFooNew rather than implementing it as a child interface. This may make it easier to remove IFoo later, especially if someone explicitly implements the interface.

Consider the following:

public class Foo : IFoo {
    void IFoo.Test() {}
}

After upgrading to your new version (v2), they will now get your Obsolete compiler warning, and at some point, hopefully they'll change so they implement IFooNew instead of IFoo and change all references. But since they're using explicit implementation, they have to leave the implementation as IFoo.Test instead of IFooNew.Test:

public class Foo : IFooNew {
    void IFoo.Test() {}
}

They no longer get the compiler warning, and everything is fine. The next version of your library (v3), you move the Test method into IFooNew, eliminate IFoo, and now they upgrade again to your newest version - they now have to change their code again.

public class Foo : IFooNew {
    void IFooNew.Test() {}
}

Ideally, you would only force them to change their code once instead of twice.