3

There is scenario where I have Interface X, which has been implemented with my thousands of classes. Now I want to add new method in that Interface X. So how to make the changes in minimal way to solve the problem of overridden of methods in all my classes.

Please don't add default methods of Java 8 in the answers.

closed as too broad by Doc Brown, gnat, GlenH7, user40980, user22815 Mar 8 '15 at 2:22

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    If the interface is implemented by thousands of classes none of which share any parent class, the first step is to refactor this coding horror. Only then a new method (a new feature) should be added. – Arseni Mourzenko Mar 7 '15 at 13:53
  • well, this is a interview question and you are given a situation. So even it's code smell you have to come up with a optimal solution. – Atul Mar 7 '15 at 14:30
  • @Atul: what do you think is wrong with the solution MainMa suggested? – Doc Brown Mar 7 '15 at 14:43
  • 1
    This question doesn't really give enough information. Will the implementation for this new method be the same in all the classes? Do we assume that classes which consume your existing interface implementations will need this new method in the future, or will that only be true of new classe? – Ben Aaronson Mar 7 '15 at 15:22
  • 1
    "Please don't add default methods of Java 8 in the answers." Oh really? And why not, exactly? Seems like this is exactly what Java 8's default methods were intended for. Do these bizarre brain-teasers really help find the best candidate, or just the candidate who's heard the brain-teaser before? – Kyralessa Mar 8 '15 at 20:19
11

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.

2

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.

  • 3
    What? Why? A class with a thousand subclasses is much more questionable. Some interfaces, like Iterable, Comparable, Collection, or Runnable are simply very general and apply to a lot of otherwise unrelated classes. – user7043 Mar 7 '15 at 14:59
  • It's not really all that smelly. What the classes have in common is the interface which, in other languages, would simply be an abstract class. – Blrfl Mar 7 '15 at 15:14
  • You certainly don't need a single common base class, but not being able to boil that behaviour down to less than the thousand classes because every single class of the thousands has an interface implementation of it's own... that should be so rare that the statistics should say "code smell" rather than "one of those super rare cases where that's ok". – nvoigt Mar 7 '15 at 15:17
  • 3
    I don't know why a thousand classes doing a thousand different things seems so unusual. – Robert Harvey Mar 7 '15 at 15:33
1

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.
1

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.

  • In Java, you don't really need to throw an exception. Should users try to invoke a method that is found in the interface but missing from the implementation you will get the following exception at runtime: java.lang.AbstractMethodError: <method signature>. I suspect C# does the same. – Gili Oct 8 '16 at 16:05
  • At the point when this answer was written, not implementing the abstract method was a compiler error in C#. – Michael Shaw Oct 8 '16 at 16:19
  • How can it be a compiler error? If the module containing the interface is compiled at a different time than the module containing the implementation, you can add a new method to the interface without it being aware that it's breaking an external module. Since the implementation module is never recompiled, it cannot generate a compiler error either. Something else must happen at runtime, when a user attempts to run existing code without recompiling it. – Gili Oct 8 '16 at 16:46
0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.