如果我有一个像这样的方法:
public void AddProduct(Product product)
{
}
我应该让我的所有类都实现一个接口,所以我可以这样做:
public void AddProduct(IProduct product)
{
}
(其中product是实体(映射到db表)
永远不会有银弹.接口和基类一起可以满足所有需求,但接口永远不会完全替换基类,反之亦然.
"过度接口"的潜在风险是接口难以改变,尤其是当它们传播到更多代码时.如果IProduct需要新属性,那么将其添加到接口可能需要进行大范围的更改.基类(抽象或其他)可以通过在不影响子类的情况下轻松更改基础来解决这个问题.
在另一方面,.NET不允许多重继承,因此基类分类也远非银色类.
一个有趣的旁注:我没有立即可用的源代码,但框架之父(Kwalina或Abrams或他们的同行)之一注意到接口被引入.NET主要作为多继承的替代; 而且语气是如果从头开始重写.NET,它可能会利用多重继承.