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.

Atul
  • 157
  • 1
  • 1
  • 4
  • 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 07 '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 07 '15 at 14:30
  • @Atul: what do you think is wrong with the solution MainMa suggested? – Doc Brown Mar 07 '15 at 14:43
  • I agree that it's a code smell and it's the best future proof solution. But IMHO interviewer may be looking for something like below as he wants to do minimal changes: - Declare another interface Y that extends X and let other class that need the extra method implements Y. I raised this question to understand more possible ways. – Atul Mar 07 '15 at 15:02
  • 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 07 '15 at 15:22
  • [This](http://stackoverflow.com/questions/20946663/) and [this](http://stackoverflow.com/questions/26086532) say it cannot be done. Java8 was excluded from the interview question because it contains an enhancement that makes it possible (default methods). Your proposed solution is probably the only viable one... the [Adapter Pattern](http://en.wikipedia.org/wiki/Adapter_pattern). – Robert Harvey Mar 07 '15 at 15:24
  • @RobertHarvey: those questions say it cannot be done if you are not allowed to change existing code literally. The question above is a little bit different. – Doc Brown Mar 07 '15 at 15:35
  • @DocBrown: Well, I'm assuming changing every one of the thousand classes is out of the question. So what could you do? Maybe some exotic Reflection solution? God, I hate these kinds of questions. Just fix the damn thing. – Robert Harvey Mar 07 '15 at 15:40
  • @RobertHarvey I think you're being slightly unfair. There is a legitimate question buried in there, which is _how do I change an interface when I can't change all the implementors?_ This would be the case when, for example, your interface is part of a published library. Imagine trying to add a method to [`IQueryable`](https://msdn.microsoft.com/en-us/library/vstudio/bb351562(v=vs.110).aspx). – Benjamin Hodgson Mar 08 '15 at 08:46
  • @BenjaminHodgson: Extension methods are not quite the same thing. Extension methods don't have access to the class' members. – Robert Harvey Mar 08 '15 at 15:18
  • @RobertHarvey Perhaps I chose a poor example. Pick an interface in the BCL with thousands of third-party implementors, to which it would be (to all intents and purposes) impossible to add a method. `IComparer`, perhaps. – Benjamin Hodgson Mar 08 '15 at 15:44
  • @BenjaminHodgson: I don't know how you could do it without adding another Interface. The problem just seems so mundane to me. – Robert Harvey Mar 08 '15 at 15:57
  • 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 08 '15 at 20:19

5 Answers5

12

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
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.

nvoigt
  • 7,271
  • 3
  • 22
  • 26
  • 4
    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. –  Mar 07 '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 07 '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 07 '15 at 15:17
  • 3
    I don't know why a thousand classes doing a thousand different things seems so unusual. – Robert Harvey Mar 07 '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.
InformedA
  • 2,991
  • 2
  • 19
  • 28
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.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
  • 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: `. I suspect C# does the same. – Gili Oct 08 '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 08 '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 08 '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.

computerGuyCJ
  • 129
  • 4