今天我遇到了一个幽灵方法，诡异至极，虽然我确信这个方法没有被调用过，无论是通过打断点，还是添加输出代码，我都在运行时验证了这一点，但诡异的是，那些只受该方法影响的变量，就是发生了改变。所以这是一个没有被调用，却又明显调用过的方法，一个幽灵方法。
这个方法大概是这样的：
public class Weight {
......
public virtual Weight setValue(double weight) {
isSet = true;
nextWeight1 = null;
nextWeight2 = null;
this.trueWeight = (float)weight;
return this;
}
}
该方法会在值被设置的时候，做一些清理工作。
但出现幽灵现象的其实不是这个方法本身，问题发生在Weight的子类BiWeight身上。在我的逻辑中BiWeight的对象是没有机会调用到这个方法的，因此我也就没有重载这个方法在BiWeight中的实现。但最近我在调试中，需要查看BiWeight的内部变量的值的时候，却发现了一些诡异的现象。
我检查了代码，确认唯有在这个方法中，isSet才有可能会被设为true，因此这个方法千真万确地被调用过。
为了确定这一点，我在BiWeight中重载了这个方法，并加了断点。
运行，断点没有被触发。我怀疑可能是被编译器优化掉了。
于是我添加了输出语句。
运行，没有相应的输出。
这么看来，这个方法应该没有被调用才对。
于是我有修改了实现，不再调用父类的方法。
运行，于是诡异的一幕发生了。
内存状态确实变化了。
但是一个没有被调用的方法是如何影响到对象的内存状态的呢！！！
难道遇到鬼了？我写了这么多年的代码，撞见鬼打墙了？为什么会存在一个这样的幽灵方法呢？
在随后的一两个小时里，我对此进行了反复测试，测试结果仿佛指向了一个规律，对象的内存状态在告诉我，幽灵方法确实被调用了，而程序的外部输出又在告诉我另一个事实，幽灵方法并没有被调用。可是为什么呢？为什么程序会有内外两种表现？
身心俱疲的我陷入了绝境。
忽然，我注意到了内存状态中的一个展示项：TrueWeight。
TrueWeight是一个属性！！！
那一刻，我仿佛听见一个遥远的声音传来，真相只有一个！！！
在这个程序中，TrueWeight属性并不是对trueWeight的简单封装，他还有一些额外的逻辑：
public double TrueWeight {
get {
if (!isSet) {
if (nextWeight1 != null) {
setValue(nextWeight1.TrueWeight);
} else if (nextWeight2 != null) {
setValue(nextWeight2.TrueWeight);
}
setValue(infinitesimal);
}
return trueWeight;
}
}
我想，在C#编程实践中，在对属性的访问时，会执行一些附加的逻辑这种做法应该是相当普通的现象。而当我在查看对象的内存状态时，IDE同时也把对象附带的属性也显示出来。那么当IDE去访问属性时，会不会也触发了这些逻辑呢？
为了验证的我想法，我编写了一个简单的程序。
public class TestClass {
public int v = 0;
bool isSet = false;
public int TestPropety {
get {
if (!isSet) {
isSet = true;
setValue(1);
}
return v;
}
}
void setValue(int i) {
Console.WriteLine($"setValu({i})");
v = i;
}
public static void Main() {
TestClass test = new TestClass();
Console.WriteLine($"value = {test.v}");
}
}
直接运行该程序的结果是这样的：
随后，我给程序打了断点：
运行，程序如预料之中的那样停在了Main方法体内的断点处，此时，我查看了一下test对象的内存状态：
setValue方法体内的断点没有触发，好像什么都没有发生一样。但v的值确实发生了变化。
我放开断点，继续运行，程序的输出如下：
我看到了setValue方法内的输出。
现在程序究竟发生了什么已经昭然若揭了。
在测试程序的自然运行过程中，setValue方法确实没有被执行，因此相关的输出是不可见的。但当我在程序运行过程中去查看对象的内存状态时，IDE会收集对象的字段和属性的值以供显示，而这一操作会触发属性的内部逻辑，从而导致对象的状态被修改，甚至影响到了程序的最终结果。换句话说，我的调试行为影响到了程序的行为。
在我的认知里，我一直认为C#的属性和Java的set/get方法是差不多的，无非是属性要更强大一些，能够做一些set/get方法做不到的事情。但现在看，属性有点儿强大过头，最起码，Java的任何IDE都不会在你查看内存状态的时候，把set/get方法的返回值也一并显示出来，并牵一发而动全身地做了一些你意想不到的事情。当然，事实上，问题不在于C#的属性设计得有问题，至少在程序自然运行状态下，一切都是自然，妥帖的。存在问题的是IDE的行为，在明知道收集属性的值会触发属性中包含的逻辑的情况下，还这么做，不是傻就是坏。
这种结果带有巨大的迷惑性，出现问题的地方和导致问题的地方相距甚远，而且无声无息，说不好哪天就会因此而栽跟头而毫不知情。你可能会疑惑，测试程序中的属性输出明明可以看见，为什么我之前却说没有看见？但那是在已知调试行为会影响程序运行的前提下，我才能够看见，换言之，我必须在查看了对象的内存状态之后再去查看输出才行，如果没有这个意识，或者没有依据这个顺序，都是无法看到输出的。而且，大多数情况下，我们都不会在访问属性时输出信息，也就意味着，即便出现问题，我们基本是无从得知的。这个情况要是再和程序中存在的错误逻辑叠加在一起，后果绝对是灾难性的，如果我们不知道我们调试的本身可能会影响到程序的行为，我们可能永远都搞不清楚问题到底出在哪里。
如果IDE坚持这么做的话， 那么我对大家的建议是，尽量不要在属性中附带可能修改对象内存状态的逻辑，或者如非必要，尽可能使用set/get方法来替代属性。但如果我们这么做，属性的价值又何在呢？鸡肋吗？
最后，我的程序并没有bug，真是瞎耽误工夫~
