何时使用属性而不是函数
这可能是个人喜好的问题，但是何时在代码中使用属性而不是函数
例如，要得到一个错误日志，我可以说
string GetErrorLog() { return m_ErrorLog; } 或者我可以
string ErrorLog { get { return m_ErrorLog; } }
你如何决定使用哪一个？ 我的用法似乎不一致，我正在寻找一个好的总体经验法则。 谢谢。
如果以下情况属实，我倾向于使用属性：
- 该属性将返回一个单一的逻辑值
- 涉及很less或没有逻辑（通常只是返回一个值，或做一个小的检查/返回值）
如果以下情况属实，我倾向于使用方法：
- 返回值将涉及重大的工作，即：将从数据库中提取，或者可能需要“时间”
- 涉及到相当多的逻辑，无论是获取或设置值
另外，我build议您查看微软的“财产使用devise指南” 。 他们build议：
成员是逻辑数据成员时使用属性。
使用以下方法时：
- 该操作是一个转换，如Object.ToString。
- 该操作非常昂贵，您想要与用户沟通，他们应该考虑caching结果。
- 使用get访问器获取属性值会产生可观察的副作用。
- 连续两次调用成员会产生不同的结果。
- 执行顺序很重要。 请注意，types的属性应该能够以任何顺序进行设置和检索。
- 该成员是静态的，但返回一个可以更改的值。
- 该成员返回一个数组。 返回数组的属性可能是非常具有误导性的。 通常有必要返回内部数组的副本，以便用户不能更改内部状态。 这加上用户可以轻易认定它是索引属性的事实导致代码效率低下。 在以下代码示例中，每次调用Methods属性都会创build一个数组副本。 结果，数组的2n + 1个副本将在以下循环中创build。
这里是微软的指导方针：
select属性和方法
如果成员表示该types的逻辑属性，则考虑使用属性。
如果属性的值存储在进程内存中，并且属性只提供对该值的访问权限，请使用属性而不是方法。
在以下情况下，请使用方法而不是属性。
该操作比字段设置要慢几个数量级。 如果你甚至考虑提供一个asynchronous版本的操作来避免阻塞线程，那么这个操作很可能是一个非常昂贵的属性。 尤其是，访问networking或文件系统的操作（初始化之外的操作除外）最有可能是方法，而不是属性。
该操作是一个转换，如Object.ToString方法。
每次调用时，操作都会返回不同的结果，即使参数不变。 例如，NewGuid方法在每次调用时都会返回一个不同的值。
手术有明显的可观察的副作用。 请注意，填充内部caching通常不被视为可观察的副作用。
该操作返回内部状态的副本（不包括堆栈中返回的值types对象的副本）。
该操作返回一个数组。
当清楚语义是“从对象中获取一些价值”时，我使用属性。 然而，使用一种方法是一种很好的沟通方式，“这可能需要更多的努力才能返回”。
例如，一个集合可以有一个Count属性。 它合理地假定一个集合对象知道当前有多less项目，而实际上不必循环它们并对它们进行计数。
在这个假设的集合上可以有GetSum（）方法，它返回所有保存的项目的总数。 集合只是一个简单的Sum属性，但通过使用一个方法，它传达了这个集合将不得不做一些真正的工作来获得答案的想法。
我永远不会使用一个属性，如果我可以影响多个领域 – 我总是会使用一个方法。
一般来说，我只是使用公共stringErrorLog {get; 私人设置 }语法的属性和使用方法的一切。
除了里德的回答，当财产只是一个getter像获取资源，如事件日志可能是。 我尝试只使用属性，当属性将是副作用免费。
如果一个属性中发生的事情不止一件事，那么它应该是一种方法。 例如，如果您的ErrorLog getter属性实际上正在读取文件，那么它应该是一个方法。 访问一个属性应该是快速的，如果它正在做很多的处理，它应该是一个方法。 如果访问属性的副作用是类的用户可能不期望，那么它应该可能是一种方法。
有一个.NET框架devise指南的书，详细介绍了这种东西。
