In Java, is there a performance gain in using interfaces for complex models?

Question

The title is hardly understandable, but I'm not sure how to summarize that another way. Any edit to clarify is welcome.

I have been told, and recommended to use interfaces to improve performances, even in a case which doesn't especially call for the regular "interface" role. In this case, the objects are big models (in a MVC meaning), with many methods and fields.

The "good use" that has been recommended to me is to create an interface, with its unique implementation. There won't be any other class implementing this interface, for sure. I have been told that this is better to do so, because it "exposes less" (or something close) to the other classes which will use methods from this class, as these objects are referring to the object from its interface (all public methods from the implementation being reproduced in the interface).

This seems quite strange to me, as it seems like a C++ use to me (with header files). There I see the point, but in Java?

Is there really a point in making an interface for such unique implementation? I would really appreciate some clarifications on the topic, so I could justify not following such kind of behavior, and the hassle it creates from duplicating all declarations.

---

Edit: Thanks everybody for the answers, it was really helpful and instructive (most of them, not only the "accepted" one).

There is clearly no advantage in performance, and I now have a larger scope of the interest that can come from it (depending on the situation), besides the usual OO role of the interface.

Answer 1

Using interfaces has not much to do with performance (except maybe the performance of the development team, i.e. the speed of development). It is more about keeping dependencies under control, and separating unrelated parts of the program.

If you depend directly on concrete class C in your code, that code is more difficult to unit test, among others. If you instead depend on an interface, it is a snap to create a mock implementation in your unit tests.

Of course, you may not need to pull up all the methods of your class into the parent interface. In fact, you may not need one single parent interface. Analyze the usage of that class and (especially with a big class like yours) chances are, you find two or even more distinct groups of methods, used by different clients (e.g. one group of clients only queries object state, while the other updates it). This makes it possible to create two or more distinct interfaces, which are much simpler and cleaner each.

This analysis may even lead to the conclusion that your class is trying to do too many things (instead of having a single responsibility), and you would be better of extracting some of its contents into a separate class! In other words, once you start thinking about - and programming to - interfaces, you start to see design on a different level, and this may lead to better design solutions.

All this told, if after all the analysis above you still see no use of the interface for your model class, make a note about it. Revisit it after, let's say, half a year. Then, if you still feel it hasn't paid for itself, just dump it. Interfaces - like any other element of your program - should always have a clear purpose and a reason to exist (and a better one than "my coworker told me to create it"). They are no panacea. If you use them cleverly, you make your code better. If you use them stupidly, you make your code even worse. The fact that you posted this question here means you want to learn how to use them cleverly, which is good :-)

Answer 2

First of all, interfaces do not have any performance benefit. If anything, the use of polymorphic code and dynamic dispatching (like C++ virtual functions) carries a cost.

Think of interfaces not as something that adds expressive power, but as something that constraints you into writing better. Interfaces are important, IMHO, for three reasons:

1) They can help you write code with better encapsulation, data hiding, stability, etc.

2) They can help you separate behavior and implementation by thinking about what you are trying to represent rather than how to implement it. Not being able to add state does a lot to prevent you from adding it accidently.

3) They let you extend things in the future and separate your code into independent units. Each component knows only what it needs to know about other services.

You can do some of this with abstract classes that have no state, but interfaces are specifically meant for this and carry the benefit of multiple subtyping. In C++, such abstract classes are often used to mimic interfaces.

Now if you can write a huge system with the perfect level of encapsulation directly with classes, that's great. But with classes there is often a temptation to bring in state prematurely and create connections.

Should you always write interfaces? Of course not. Always be afraid of "Always" rules :) It's always a balance between wasted work and =useless complexity and the benefits. With time and experience, you get the instinct for it.

Also, header files are essentially interface files. They generally define allowed behavior but no state. If you learn C and then Java (some schools do that), you learn about ADTs in C, and then about ADTs in Java using interfaces.