Question

如果我的方法如下：

public void AddProduct(Product product)
{

}

我是否应该让所有类都实现一个接口，以便我可以这样做：

public void AddProduct(IProduct product)
{

}

（其中product是实体（映射到db表）

Answer 1

永远不会有银弹。接口和基类一起可以满足所有需求，但接口永远不会完全替换基类，反之亦然。

“过度接口”的潜在风险是接口难以改变，尤其是当它们传播到更多代码时。如果IProduct需要新属性，那么将其添加到接口可能需要进行大范围的更改。基类（抽象或其他）可以通过在不影响子类的情况下轻松更改基础来解决这个问题。

在另一方面，.NET不允许多重继承，因此基类分类也远不是一个银币。

一个有趣的旁注：我没有立即可用的源代码，但其中一个框架父亲（Kwalina或Abrams或他们的同行）注意到接口被引入.NET主要作为多继承的替代方案;而且基调是，如果从头开始重写.NET，它可能会使用多重继承。

Answer 2

大多数情况下，你可以换掉单元测试的交互，这就是你使用界面的原因。

如果您只是将Product用作POCO，那么我就不会。

Answer 3

原则是你的方法应该尽可能少地了解传入的对象。如果接口是实现它的最佳方法，那么肯定使用接口。但还有其他方法。

例如，如果您的Customer对象具有LastName属性，您只需要在方法中读取，而不是使用Customer参数，请使用名为的字符串参数lastName，然后传入myCustomer.LastName。

Answer 4

我将接口视为契约行为的方式。这样，实现该接口的任何内容都应该强制执行您在界面中设置的任何合同。

因此，如果传递的对象包含您的对象必须使用的行为，我只会使用接口。这主要是为了在测试时，您可以使用模拟对象切换该对象，以确保它正常工作。

由于POD不包含行为，我不会将它们连接起来。这是因为我认为没有衍生的好处。如果您的POD的数据类型或内容发生变化，那么无论是否由接口缓冲，您都将在POD使用的任何地方进行彻底的更改。嘲笑POD进行测试没有意义，因为模拟看起来就像真实的一样。

Answer 5

每一个参数？绝对不。接口可以增加灵活性，在某些情况下可以减少维护（但可以在其他情况下显着增加！），但它们确实增加了代码的复杂性。

您给出的示例似乎是对接口的合理使用。与您在设计程序时做出的所有其他决策一样，您需要单独考虑每种情况。但是，只需用接口覆盖所有内容就可以解决疯狂问题。