should every single parameter use an interface?

Question

If i have a method like:

public void AddProduct(Product product)
{

}

Should I have all my classes implement an interface so I can do:

public void AddProduct(IProduct product)
{

}

(where product is an entity (maps to a db table)

Answer 1

There's never a silver bullet. Interfaces and base-classes together can cover near all needs, but interfaces never fully replace base classes and vice-versa.

The potential risk of "over-interfacing" is that interfaces are difficult to change down the road, especially as they propagate into more an more code. If IProduct needs a new property then adding it to the interface has the potential to require widespread changes. Base-classes (abstract or otherwise) can remedy this by making it easy to change the base without affecting subclasses.

On the flip-side .NET doesn't allow for multiple inheritance, so base-classing is far from a silverbullet as well.

---

An interesting side-note: I don't have a source immediately available but one of the framework fathers (Kwalina or Abrams or a peer of theirs) notes that interfaces were introduced to .NET largely as an alternative to multiple-inheritance; and the tone was that if .NET were to be rewritten from scratch it would likely utilize multiple-inheritance.

Answer 2

Mostly so you can swap out interactions for Unit-Testing is why you'd use an interface.

If your simply using Product as POCO, then I wouldn't.

Answer 3

The principle is that your method should know as little as possible about the objects being passed in. If an interface is the best way to achieve that, then sure, use an interface. But there are other ways.

For instance, if you have a Customer object with a LastName property that you just need to read in your method, instead of having a Customer parameter, have a string parameter named lastName and just pass in myCustomer.LastName.

Answer 4

Every single parameter? Absolutely not. Interfaces can add flexibility and in some cases reduce maintenance (but can add to it significantly in others!), but they do add complexity to your code.

The example that you've given seems like a reasonable use of an interface. Like every other decision you make when designing your program, you need to consider each situation individually. But just blanketing everything with interfaces would be a road to madness.

Answer 5

I view interfaces as a way to contract behaviour. This way, anything implementing that interface should enforce whatever contract you set out in the interface.

So, I would only use an interface if the object being passed contains behaviour that your object must use. This is mostly so that, when testing, you can switch that object out with a mock one to ensure it's working correctly.

Since PODs do not contain behaviour, I would not interface them. This is because I see no derived benefit. If the data types or content of your POD changes, you are going to have sweeping changes everywhere that POD is used whether that was buffered by an interface or not. And there's no point in mocking a POD for testing, because the mock looks just like the real thing.