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.
This question targeted C#, but I think it applies as well. The highest voted answer says that defining an interface for every class is just code noise.
In fact, using interfaces instead of classes allows you three things :
Interfaces are incredibly overused in Java partly because of the language design and partly because people think making lots of interfaces is good design.
Abstract classes would be superior to interfaces if Java allowed multiple inheritance. Scala a new programming language for the JVM has a concept of Traits which are essentially abstract classes with MI capability.
The advantage to an abstract class is that you can add behavior to the abstract class with out breaking existing classes that extend it. Thus an abstract class is also better as an extension mechanism (plugin) then interfaces.
Unfortunately JMock and its brethren encourage lots of interfaces for BDD testing but this is not necessarily true because there are at least a couple of libraries to mock concrete objects.
Here's 2 links that explain why you'd want to do this:
http://www.artima.com/lejava/articles/designprinciples.html http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html
It has nothing to do execution performance(more to do with programmer(you) performance), in that you're decopling users of a class from its implemenation - among other things for easing testability and maintainability.
Maybe not this year, but next year there might.
Yet another way to misuse interfaces?
There are no obvious performance gain using interfaces. Conversely, it may have a negative performance impact due to RTTI (Based on your compiler's features)
There is a relatively common development dogma that there should be an interface for pretty much everything. As far as I can tell, this is based either on a cargo-cult mentality in regard to "program to an interface, not an implementation" (which most definitely does not require you to litter you code with interfaces all over), or on doing test-driven-development with older mocking frameworks that couldn't mock concrete classes.
Disregard such nonsense.