Today I came to a fundamental paradox of the object programming style, concrete types or interfaces.
Whats the better election for a method's return type: a concrete type or an interface?
In most cases, I tend to use concrete types as the return type for methods. because I believe that an concrete type is more flexible for further use and exposes more functionality.
The dark side of this: Coupling.
The angelic one: A concrete type contains per-se the interface you would going to return initially, and extra functionality.
What's your thumb's rule?
Is there any programming principle for this?
BONUS: This is an example of what I mean ReadOnlyCollection or IEnumerable for exposing member collections?
My rules of thumb:
1) Initially, I have the method return the interface type, because its always easy to change it to the concrete type later if necessary. Harder to go back the other way.
2) Even if the method is declared to return the concrete type, I would code the callers to use the interface type whenever possible:
InterfaceType i = xyz.methodThatReturnsConcreteType();.
3) Whether I own the calling code makes a difference too (internal vs public APIs):
- If I own the code that calls the method in question (i.e. internal API), then the more willing I am to return the concrete type.
- If I don't control the code that calls this method (e.g. public API), the more likely I am to return the interface type instead. Returning the concrete type is a commitment and, generally speaking, the less I promise, the easier.
Other considerations:
- Testing may be easier with interfaces since I can use a mock object that implements the interface.
- There's an outside chance that I would want to return a proxy object (now I'm really reaching for excuses)
In summary,
- I usually return the interface type because I feel the benefits of loose-coupling outweigh the convenience of having full access to the concrete type.
- However, I'm not opposed to switching to return the concrete type on a case-by-case basis whenever the convenience outweighs the benefits of loose-coupling.
Rule of thumb, in return types, be a as specific as possible, in parameter types be as unspecific as possible. Also prefer interfaces, since you may later exchange your implementation if necesary, without changing the clients of your API.
Interesting question. I believe you have to ask yourself how can the return data be used. Using the age old car analogy if you had
public AccelerationResponse PressAccelerator(float force) {}
Chances are that you'd want to return an interface rather than a class. You could be interpreting this response differently depending on certain conditions.
If you are guaranteed that your return can only be used in the manner expected by the concrete implementation then using that class makes sense. I'm not sure of any widely accepted principle but my rule of thumb is if the return type can be reused in different implementations an interface makes more sense.
