First thing I would try in this situation is to avoid an interface change at all. You could add an extended interface, derived from the original one, with the new method added, and make the code which uses that interface in combination with the new method expecting to get an object of type “ExtendedInterface”.

If that is not possible, for example because the code in stake is outside of your control, you could add an abstract class with a default implementation for the new method in the inheritance hierarchy between the interface and all derivations. Even for thousands of classes, the necessary changes in the code base can probably be made in a few hours with some global searching/replacing, or by creating a small script or helper program, with a low risk of breaking something.

Which of this approaches is better depends on which part of the code base you are actually allowed to change, and what “minimal way” actually means.

The comment is correct, if you really have thousands of classes and no common base class, that’s a code smell that should be solved first. Classes that share a common interface but no code whatsoever should be rare.

Otherwise, use a tool. Resharper for C# for example will give you an option to actually implement that method in all classes that implement the interface. That’s obviously only a part of the work to be done, but at least it still compiles. For literally thousands of classes, I guess writing your own tool would still come ahead of doing it manually.

This is a practice that I have seen in the industry.

• They create a new interface with a number appended, for example Interface2 and make this contain methods in the old interface.
• Make the old interface deprecated
• When there is a major overhaul, a new package will most likely be added in (think about the overhaul when Java JDK introduces the new mechanism for file and IO in nio). This is the time to remove the number from the interface, having a new interface in a different package

This approach allows new methods in the interface, you can have very flexible solution for various way to implement the new interface.

• It doesn’t break existing users.
• It provides a buffer period when the changes can consolidate and/or be experimented before the old interface is actually removed after deprecated.

There are several issues to consider, before deciding how to make the code change.

Consider the case when third parties have written code that uses or implements this interface. That would significantly increase the complexity of managing the code changes required, as well as adding a political element to the process – creating work (and cost) for other companies.

As this interface has already been implemented in many classes is a strong indicator against making changes to the current interface. The consequence on all the implementations of this new interface method need to be considered.

The fact that all these implementations have been completed without needing this new method is a warning flag that perhaps this is not really core to this interface purpose, and that this should be implemented as a new separate interface on the basis that this is a separate (but related) use of the object, and requires its own interface.

That said, assuming that we control all code that uses this interface, I would implement the new method in all classes implementing the new method explicitly.

e.g.

public class MyObject : ITheInterface
{
    public void ITheInterface.NewMethod(int age)
    {
        throw new NotImplemented("NewMethod needs to be implemented on MyObject");
    }
}

By implementing the method explicitly like this, code only calls the new implementation when it is using a reference typed as ITheInterface for the object.

The lesser of two evils, if you are not allowed to refactor the implementing classes, is to not add the method to the interface. There is no reasonable situation where you should break compatibility with the existing interface. The new method belongs in a new interface, and any class that needs to use it will have to implement the new interface. Chances are, not all 1,000 classes that implement the existing interface will need the new method, and if you force them to you will end up with tons of empty implementations, which will be a waste of time and screen space for anyone involved in maintaining the code.

Regardless of the answer you end up giving for this question, I would seriously question whether or not you want to work for this company. If this is a common concern for them, then they clearly don’t know what they’re doing. If they don’t actually have these types of issues, then they’re wasting your time with a pointless interview question. Nothing good can come of this.