Interfaces as parameters

Question

In what scenarios would somebody pass (or receive) an interface as a parameter? Is it really a useful thing or just a fancy way of doing something?

Answer 1

It's an extremely useful thing.

Take any of the LINQ extension methods, for instance. They don't care what's passed to them, as long as it implements IEnumerable<T>. The idea is that they can all be applied to anything that you can enumerate over using a foreach loop.

Imagine how pointlessly restrictive it would be if they all required you to pass T[] arrays, or List<T> objects, for example.

---

Here's just one very trivial illustration. Let's pretend the LINQ extensions don't exist (which is actually a real possibility if I'm using .NET 2.0) and I want to write a Sum method.

I could write it like this:

public static double Sum(List<double> values)
{
    double sum = 0.0;
    foreach (double value in values)
    {
        sum += value;
    }
    return sum;
}

That's all well and good, but notice something here: I wrote the method to take a List<double>, which is a class that has far more functionality than this code depends on. Where does it use Insert? Where does it use RemoveAt? FindAll? Sort? Nope, none of that is required. So is it really necessary that this method get passed a List<double>?

Moreover, say I have a double[]. Theoretically, I should be able to pop that right in as the values parameter, since all I'm doing is enumerating over it using a foreach; but since I've typed values as List<double>, to pass a double[] to my Sum method I'd have to do this:

double sum = Sum(new List<double>(myArray));

That's just a completely unnecessary new object I've constructed simply to call code that really should've been able to handle my original object in the first place.

By writing methods that take interfaces as parameters, you make your code more flexible and more powerful, and you avoid imposing inappropriate restrictions (give me an X, even though I could just as easily do this with a Y) on calling code.

Answer 2

The easiest way to remember, is that it's all about programming to the interface, not the implementation. Say for instance, I have a method where I want to do something, e.g.

public void MakeNoise(IAnimal animal)
{
  animal.MakeNoise();
}

I don't care what the specific implementation is, I just know that whatever is passed in, I can call MakeNoise(). I program to an interface, not an implementation.

public class Dog : IAnimal
{
  public void MakeNoise()
  {
    Console.WriteLine("Woof");
  }
}

public class Cat : IAnimal
{
  public void MakeNoise()
  {
    Console.WriteLine("Meow");
  }
}

Interface programming is a core aspect of OOP, you'll find them incredibly useful.