【发布时间】：2011-12-15 01:15:41
【问题描述】：
谁能帮我看看在接口或抽象类上包含属性是否是最佳实践？
我想一个接口应该只有方法签名？
【问题讨论】：
-
怎么是骗子？正如凯尔在下面指出的那样，接口和抽象类都可以具有属性，因此没有“vs”。在这里。
【发布时间】：2011-12-15 01:15:41
【问题描述】：
我认为没有最佳实践。
接口上允许使用属性（实际上是方法）。除此之外的任何内容都只是一种意见。这包括我关于任何更多的观点的观点。
【讨论】：
在接口中拥有属性是完全可以接受的。我一直这样做。
【讨论】：
-
也许这只是一个偏好问题。好吧，我会忘记这些争论，照你的做。
属性是方法的语法糖。考虑一下：
我有一个财产：
String PropertyA { get; set; }
在运行时会变成这样：
String get_PropertyA() { ... }
void set_PropertyA(String value) { ... }
请注意，“...”表示将由代码生成器放置在那里的代码。实际上，我要说的是，属性实际上并不存在于 C# 之外，因为它们使用我的示例中指示的对流编译为方法。要确认我在说什么，您可以使用反射并查看反射代码的样子。
将属性放在接口上可能是不好的做法，如果它们在实现中做了一些不重要的事情。例如，如果我想设置一个变量并更新其他变量，或者设置一个属性可能会因为内部条件而拒绝我的属性分配，那么不应使用一个属性。我认为这是适用于接口之外的一般规则。
【讨论】：
-
正如您所指出的那样，做一些不平凡的事情对于财产时期来说是一种不好的做法。它会导致调试器出现问题，并且该类的使用者不清楚将完成重要的工作。对于接口，您无法确定它是否重要，因为它没有实现。您所能做的就是通过名称暗示不平凡的工作 - 但根据定义工作。自然暗示了一种方法。
-
仅使用 getter 属性对 DTO 接口非常有意义。
-
我们如何定义非平凡？我一直在努力决定在我的接口属性或方法上创建一些成员。在一种实现中，它将是字段的直接集合/获取，但在另一种实现中，它将需要执行正则表达式以从字段成员中提取值。如果我们还不知道接口的各种实现，我们怎么知道它是否重要？
-
我会根据你的描述（这是这里的观点）建议你考虑一下架构以及你的课程的目的是什么。如果您的类有一个目的，例如充当 DTO 对象等，那么您可能会发现，虽然期望的结果是过滤等，但过滤是 DTO 对象的核心意图的附加内容（因此应该在一个单独的类中理想情况下，以免使单一责任理念无效）。
-
但是，您可以与我所说的相反，即您的课程的目的是以您想要的方式或以高性能的方式传输数据（不存储垃圾）不需要的数据等）。这些也可能是合理的担忧。这真的取决于您的业务需求。我会尽量保持 DTO 过于干净，并扩展它们以获得我想要的东西，因为它实际上是一个充当合同的类，并且将业务需求放入 DTO 感觉是错误的。我更喜欢从我的 DTO 中排除辅助方法。保持你的单一职责。
界面中的属性很好
见：
http://msdn.microsoft.com/en-us/library/ms173156.aspx
接口由方法、属性、事件、索引器或任何 这四种成员类型的组合。接口不能包含 常量、字段、运算符、实例构造函数、析构函数或 类型。它不能包含静态成员。接口成员是 自动公开，并且它们不能包含任何访问修饰符。
【讨论】：
-
仅仅因为它是可能的并不意味着它是 OP 要求的最佳实践。
在接口或抽象类中包含属性是完全有效的。
【讨论】：