When developing in OOP, sometimes an interface / contract is given by a library that you cannot alter. Let's call this interface J.

Now you have an object of class A that consumes objects that implements this interface. Inside A only a small part of the interface's definitions are needed. Some of the object classes are created by me during the project (let's call one of them type D), so there's an overhead in the implementation of everything inside interface J.

I want to implement a subset of the functionality in interface J, but my solutions so far do not satisfy me:

  • implementing every aspect of J and then throwing "notImplementedExceptions" misinforms the user of my objects: it would seem my objects of type D do conform to interface J, but they don't - and other consumers of my objects (that accept objects implementing interface J) can't rely on the integrity of my objects.
  • Implementing a newly defined interface prohibits me from using objects that implement only interface J, although interface J is fully compatible with my own interface.
  • Letting my custom objects implement interface J would create significant overhead, because they don't need all this functionality.

When I was able to alter interface J, I would create a "super-interface" K that had this subset of the functionality of interface J, and make interface J inherit from interface K. But I cannot alter interface J.

What is an object-oriented solution to this problem? Is the best solution still implementing "just" interface J? Or are there OOP-ways to "superclass" an interface without altering it?

  • 1
    See how the *Adapter classes in Swing do this.
    – user1249
    Jun 1, 2011 at 9:07

6 Answers 6


if you don't control the interface J, you're stuck.

you can, for clarity, implement your own interface subJ and interface J, and use subJ in your own code to make it clear that the extra methods in interface J are not required, but i don't think that really gains you much

if possible, implement the entire interface J completely

if possible, contact the owner of interface J and ask him/her to alter it to better suit your purposes

  • 2
    As a compromise: You can ask the owner of interface J to inherit form your smaller interface SubJ.
    – k3b
    Jun 1, 2011 at 10:16

The whole point of implementing an interface is to provide a firm contract between the caller and the callee that never changes while the implementation details may vary.

By implementing interface J you are telling the outside world what you can do.

If you don't need half of what J does then either the interface should really be subdivided as it's not as small as it could be, or you have to throw NotImplementedException on the methods and properties you don't need. However, this is not the best solution as it confounds people's expectations of what your code can do.


If your consumer class A does not require all of interface J, then I would suggest creating a new interface (call it K), that comprehensively describes all that it does require.

This provides a clear signal to anyone using class A as to what their side of the contract is. Thereby improving the chances of reuse. If someone needs to provide an object that implements a large and complex interface, in order to do something relatively simple, they will likely end up writing whatever class A does themselves.

In order to allow class A to consume objects that implement interface J alone, you can provide a wrapper class that implements interface K and passes any appropriate calls on to an interface J member.


While I agree with the existing answers that say you really need to either implement J completely (with exceptions for not implemented methods) or not at all, a possible workaround is the following:

  • Create a smaller interface K that is a subset of J and implements the required methods.
  • Create a wrapper for A that accepts objects that implement J and K.
  • In the case of a passed in J, simply push it through to the instance of A.
  • In the case of a passed in K, instantiate an anonymous implementation of J, wiring only the methods from K to J that are there. Pass the result to the instance of A.

Please note that this is quite an ugly solution, since it requires a wrapper that accepts multiple things that are essentially the same thing. But it does achieve the following:

  • No changes to J or A.
  • No "exposed" implementations of J that are incomplete.

If your OO language doesn't allow anonymous interface instantiation, you can create a dummy implementation of the interface and instantiate that.


How long would implementing the entire interface take you?

If it would take you a considerable amount of time this indicates a design issue, and I would advise you (as Steven A. did before me) to contact the owner and see whether it can be changed in the future.

Do you use the interface in your own code, independent of the library of the interface?

As Steven A. suggested, you can use your own interface as you would like to see it in your own code. This at least keeps your inhouse code clean. You can also send this to the owner as the interface you would expect to find. Perhaps he agrees with you, or perhaps he can explain to you why the interface shouldn't be split.

Would your implementation ever need the unused members of the interface?

In case you can expect them never to be called since they 'aren't supported', I prefer using the NotSupportedException. This gives a clear indication you will never support this interface, rather than you didn't implement it.

  • Good idea on using NotSupportedException it does make it clear that you don't support that method.
    – ChrisF
    Jun 1, 2011 at 9:57
  • @ChrisF: I only use NotImplementedException for production code, where I would otherwise write "TODO: Implement this" Sadly, they don't pop up in Visual Studio's task list. But in practice, I hardly leave a method unimplemented for longer than two days. Resharper also shows those exceptions in bold (at least with my setup). :) Jun 1, 2011 at 10:04

Implement what you need, and throw an exception NoImplementedException on the others.

This is a matter of use. If you don't use the interface, or you know your code won't use the interface, then don't invest time on this, as you don't need to invest time on redundant code.

Work for the task at hand, and keep good trail for others to follow if they want to use the interface.

A lot of interfaces in Java are not implemented to the full.

This is the Apache aproach to things : http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/NotImplementedException.html

  • Perhaps argue why you do believe this is a proper solution. This adds nothing to the question. Jun 1, 2011 at 9:26
  • there is no need to implement everything, as there is no real need to explain everything. if that was his case, parts of the interface were redundant he would picked it up immediately. Jun 1, 2011 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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