我有一个有一些属性的类。我想要从这些属性中计算得分的东西。因为这是一项微不足道的任务(一些补充和分裂,但没什么了不起的。)
很自然地,问题是:“何时使用带有getter中某些代码的Property,以及何时使用函数?”和that question was already answered。
现在,我想知道一件事:如果 - 反对所有期望 - 我曾经需要让这个Getter变得如此复杂以至于它应该是一个函数(例如,因为我需要放入数据或因为它可以抛出一个异常或其他),将属性更改为方法是否容易?
当然,这似乎很简单,只是改变
public double Score {
get {
return Math.Round(A + B / C * D,3);
}
}
到
public double Score(){
return Math.Round(A + B / C * D,3);
}
但我想知道:有副作用吗?改变这样的东西会有什么破坏吗?我只能在涉及Reflection时将此视为一个可能的问题,但在我有2个Assemblies的情况下 - 一个定义类和一个使用该类 - 并且只更改包含该类的那个而不重新编译消费者部件。这是否是“几乎无法跟踪的奇怪错误”的可能来源,或者将属性更改为方法是否完全安全?
答案 0 :(得分:3)
拉起反射器,你会发现你的属性已经是方法:)
答案 1 :(得分:1)
没有。根本没有副作用。
拉起反射器,你会看到的 你的属性已经是方法
简介将属性中的get
和set
访问者转换为get_MyPropertyName()
和set_MyPropertyName()
方法。这也是您可以(但通常不应该)向属性添加参数的原因。
唯一的“问题”是在C#中你需要在任何现有的电话中添加“()”。
另外
根据编码指南,a 属性名称通常是名词(即 得分),但方法应该描述 动作(动词),所以更恰当的名字是 GetScore()或CalculateScore()
答案 2 :(得分:1)
如果您要从属性更改为方法并允许编译器向您显示添加parethesis的位置,则可能会出现微妙的错误,因为object ting = thing.score
ting
将是属性的盒装双得分的版本,但得分的方法版本的委托,因此不同的代码路径将导致:
public void erm(double param){ //stuff here}
public void erm(func<double> param) {// different stuff here}
用
打电话时erm(thing.score)
使用属性与方法版本的分数。
答案 3 :(得分:1)
一个副作用是将所有调用代码分解为此属性。您将更新所有调用者以使用方法签名而不是属性
答案 4 :(得分:0)
正如其他人已经指出的那样 - 没什么值得担心的。我只是发帖说明根据编码指南,属性名称通常是名词(即分数),但方法应该描述动作(动词),所以更合适的名称是GetScore()或CalculateScore():)
Grammar Nazi行动:)