Reputation: 7702
I'm a little confused on the concept of methods returning interfaces. Is there an article or reference that discusses this in some detail? I'm confused on when/why you might want to do this, and how is it that you can cast an interface to/from the object it's associated with (I think that's right).
Upvotes: 3
Views: 1598
Reputation: 838226
I'm confused on when/why you might want to do this,
Returning an interface is good when you want to separate the contract of what something is supposed to do, from the concrete implementation (how it does it). Having an interface allows you to reuse and modify code more easily.
If you have an interface IFoo
and an implementation SimpleFoo
that implements IFoo
in a naive way you can program against the interface and get basic functionality. Later you can make an AdvancedFoo
implementation that also implements the same IFoo
interface. Now you just need to return your new object and the rest of the code will use the new, more advanced class without requiring any changes. Having the interface also allows you to make the choice of which class to use at runtime.
When your code returns interfaces it also makes it more flexible. You may currently return a List<T>
but if the result only needs to be used as an IEnumerable<T>
then you should return this instead. Then you can later change your implementation so that the results are generated on the fly (for example with an iterator block) and the calling code will still work.
how is it that you can cast an interface to/from the object it's associated with
The whole point of interfaces is that you shouldn't need to do this. You should just use the interface without worrying about what the specific implementation is. The correct method will be called by the runtime. If you think you need to cast it could be a sign that your interface is not rich enough to support your needs.
You can cast if you need to though:
IFoo foo = getFoo();
SimpleFoo simpleFoo = (SimpleFoo)foo;
Note that this cast can fail and you may want to use as
instead:
IFoo foo = getFoo();
SimpleFoo simpleFoo = foo as SimpleFoo;
if (simpleFoo == null)
{
// Too bad...
}
else
{
// Now we can use simpleFoo.
}
Upvotes: 15
Reputation: 32515
Sometimes you want to return an interface because it's a general way of returning any class that implements it. You won't have to worry about what the actual class being returned is because you'll be able to call the methods that are in the interface.
For example:
public interface IFooBar
{
String GetData();
}
public class Foo : IFooBar
{
public String GetData() { return "Foo"; }
}
public class Bar : IFooBar
{
public String GetData() { return "Bar"; }
}
public class DataManager
{
public static IFooBar GetFooBar()
{
IFooBar foobar = ...
return foobar;
}
}
public class MainAppClass
{
public void SomeMethod()
{
//You don't care what type of class you get here
//you only care that the object you get back let's you
//call GetData.
IFooBar foobar = DataManager.GetFooBar();
String data = foobar.GetData();
//etc
}
}
Upvotes: 1
Reputation: 41209
Methods cannot return an interface itself. An interface is a description of methods an object should implement. You can't return a list of methods an object needs to have.
What you can do is return an instance of an interface. Take code that looks like this:
using System.Collections.Generic;
ICollection<int> getCollection() {
return new LinkedList<int>();
}
This method returns an instance of LinkedList, but its return type is ICollection. This means you can use the return value of getCollection() wherever you can use an ICollection since LinkedList inherits from ICollection. If the return type was LinkedList, you could only use the return type where a LinkedList was expected, reducing your flexibility.
Upvotes: 0
Reputation: 209585
I'm not sure what's confusing about it. An interface is basically equivalent to an abstract class that has no non-abstract methods and no declared state (fields). So returning an interface is like returning an abstract base class.
The reason you'd want to return an interface instead is that interfaces represent small bundles of functionality rather than full-blown objects. A classic example is returning IEnumerable instead of List because even though the underlying object might be a list, the method is really just returning an ordered set of objects and that's all the caller should see. In the future, the method might return an array or some other data structure. But it won't matter to the caller because all the caller sees is IEnumerable. This follows the general principle of programming to interfaces instead of implementations.
Upvotes: 0