接口不应该有属性?

我从未见过有人提出这种说法,我也看不出有什么好的理由。NET框架中充满了带有属性的接口。

我也会在这里加上我的声音——我从来没有遇到过这个建议。一个属性实际上是一对get/set方法。

就像其他设计决策一样。如果它真的有意义;如果它适合设计中的系统,如果它不会引起维护问题,如果它没有引起性能问题,那么你就没有理由不能这样做。

有一个被广泛认可的术语“代码气味”。我建议引入“程序员气味”的概念——如果有人坚持某种规则,但无法解释为什么——这是一种气味。你的同事应该能够解释为什么界面中的属性不好。如果他不能——即使他所指的文章是对的,他也可能错了。

那篇文章可能是在谈论一些特定类型的接口,可能与COM和互操作性有关,或者别的什么。或者他可能只是搞错了。理解规则并能够解释它们是使用规则的重要组成部分。

例如: ICollection<T> 两者都有 Count 和 IsReadOnly .

本身从未见过这样的事情,但不久前有人谈到在跨平台接口定义中不使用属性,因为有许多平台不支持属性,但几乎所有平台都支持方法。

Cause属性意味着它们很快(即获取和设置值),但由于网络和序列化活动,这对服务来说是不正确的。在服务接口中获取或设置值的显式方法意味着完成操作可能需要一些时间。

我想不出任何文件来支持这一前提。此外,我可以在BCL中想到许多相反的例子。看看几乎所有的集合接口,你都会看到属性。

实际上,一个属性由两个函数组成:一个用于获取值,一个用于设置值。尽管属性是C#的第一类“特性”,但这仍然是正确的。

为什么不允许在接口中使用属性?

IEnumerator 对于需要属性作为接口成员的场景来说,这是一个完美的例子。若不强制实现者这样做,你们将如何存储当前元素?

我看到这是一个。网络问题;然而,这种想法可能来自Java背景。这让我想起了《Effective Java》中的第22条: .

当一个类实现一个接口时,该接口充当 类型

一种未通过此测试的接口是所谓的 恒定界面

Java平台库中有几个常量接口。..这些接口应被视为异常,不应被模拟。

我同意之前的答案,即我从未见过避免同时包含属性和方法的接口的建议。