是否有任何理由为非常基本的数据对象提供接口?

时间:2010-08-16 14:34:56

标签: design-patterns language-agnostic oop

在编写我当前的项目时,我已经为所有对象创建了接口。我认为这被认为是良好的编码实践。

我基本上最终得到了一堆定义非常简单的类的接口。

例如:

public interface IUser
{
    int Id { get; }
    string DisplayName { get; }
}

我真的没有意识到在这里有这些。我现在另外在几个地方遇到问题,我想做一些事情,比如定义运算符重载,这是我在接口级别无法做到的。

我很想通过我的项目并删除所有这些接口(我会为我的存储库和其他定义更复杂行为的东西保留接口),但是我会因为删除100s而感到有点内疚代码行以及随之而来的所有重构。

我想听听其他用户的意见。是否有任何目的来定义基本对象上的接口?将它们放在那里是否有任何伤害,即使它们不是真的有必要?

7 个答案:

答案 0 :(得分:6)

如果接口没有添加值,则删除它们。当谈到实体上的接口,除非它们有共同点,我认为将它们放在接口后面并没有增加价值。

如果他们确实有共同点,那么您可以使用通用算法来处理它们。

我经常看到“实体”扩展包含审计信息的基类。

interface IAuditBase{
    int Id { get; }
    string UpdateDate{ get; }
    //etc.
}

答案 1 :(得分:4)

如果您无法定义使用它们的原因,我不会使用它们。当你有一个非常标准化的方式与一组类似的对象进行交互并且需要它们以完全相同的方式“接口”时,接口是很棒的。

我发现如果我的'界面'发生了很大的变化,那么界面是一个坏主意,我只会在我知道标准不太可能发生变化并且界面理解得很好并且有意义时使用它们。 / p>

如果您无法解释为什么使用接口,我将不得不建议不要使用它们,如果这样做没有任何好处,则无需过度复杂化。

你提到过IUser接口,那么你是否有一堆User差异的实现,它们共享一个类似的接口,类似的方法和行为等?一个接口可能有意义,但如果你只有User类,那么没有真正的理由使用接口。

答案 2 :(得分:1)

接口的要点是提供一个类将遵守的“合同”。如果多个类需要遵守相同的合同,如果某些类只需要访问接口成员而不关心类实现,那么这真的变得非常重要。

如果您不打算使用这些方案,请随意省略一些界面。

另一方面,已经定义了接口,我认为任何额外的开销都是如此之小(如果它存在的话),现在删除它将是过早的微优化。

答案 3 :(得分:0)

接口意味着对我不同的实现。如果您的模型对象不会改变行为,或者不会被代理,或者它们是不可变的,或者它们只不过是DTO,那么我就不会看到接口的原因。

答案 4 :(得分:0)

接口应该只在大多数时候被视为合同。 您定义的实体应被视为类(因为将从中创建对象)。

接口提供了一种实施的灵活性。

还有其他几个原因可能需要使用接口而不是类继承:

接口更适合于您的应用程序需要许多可能不相关的对象类型来提供某些功能的情况。

接口比基类更灵活,因为您可以定义一个可以实现多个接口的实现。

在不需要从基类继承实现的情况下,接口更好。

在不能使用类继承的情况下,接口很有用。例如,结构不能从类继承,但它们可以实现接口。

答案 5 :(得分:0)

就个人而言,我认为DTO应该很少有接口。 DTO更有可能保持静态,“接口”将是获取/保留DTO的代码。

答案 6 :(得分:0)

这就是我喜欢TDD(或类似方法)的原因之一。在重构步骤告诉您需要它们之前,您将不会获得接口。