c# - 属性和方法之间的界线应该在哪里?

标签 c# properties methods conventions time-complexity

<分区>

Possible Duplicate:
Properties vs Methods

在许多情况下,某物应该是属性还是方法是显而易见的,但有些项目可能会被认为是不明确的。

明显的特性:

  • “姓名”
  • “长度”

显而易见的方法:

  • “发送消息”
  • “打印”

不明确:

  • “有效”/“有效”/“有效”
  • “InBounds”/“IsInBounds”/“CheckBounds”
  • "AverageChildValue"/"CalcAverageChildValue"
  • “颜色饱和度”/“设置颜色饱和度”

我想我会倾向于模棱两可的方法,但有人知道有助于决定这一点的规则或惯例吗?例如。所有属性都应该是 O(1) 吗?属性是否应该不能更改其他数据(ColorSaturation 可能会更改 R、G、B 值)?如果有计算或聚合,它不应该是一个属性吗?

只是从学术的角度来看,(并不是因为我认为这是个好主意)是否有理由不对属性发疯,而只是让一切都是对类的审讯而不进行争论,以及一切可以可以通过单个参数更改类并且不能失败,一个属性?

最佳答案

如果属性具有以下行为之一,我通常会将其转换为函数

  • 产生副作用(除了设置支持字段)
  • 与现场访问相比,实现成本更高
  • 实现复杂度高于Log(N)
  • 可以抛出异常

关于c# - 属性和方法之间的界线应该在哪里?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2436428/

相关文章:

c# - 如何从对象列表创建 MVC HtmlHelper 表

android - 为什么有些 Java setter 方法会自动成为 Kotlin 属性,而有些则不会?

.net - 如何轻松找到未使用的公共(public)方法/属性

JAVA 如何将全局变量放入函数参数中?

ruby - Rails - 如何从 lib 目录调用方法?

c# - 如何通过 C# 将数据包转发到另一个端口上运行的另一个 TCPClient

在数据库插入之前使用 POCO 属性属性的 C# EF 字符串长度数据验证

java - 在调用 super 构造函数之前无法引用 'method'

c# - 为什么无法通过 PrincipalContext 联系 Active Directory 服务器?

c# - Entity Framework (3.5) - 拒绝更改