不得不说Visual Studio原来越强大，好多注意不到的小疏忽都可以轻松发现。
首先说一句，由于我有些特别的。。。偏好，所以命名有个别地方可能有点特别，这也是我最头疼命名的原因之一。
今天对整个解决方案进行分析的时候，VS提示我下面的图：
代码：
void ISerializable.GetObjectData(SerializationInfo serialization, StreamingContext context) { serialization.AddValue("Prompt", Prompt); base.GetObjectData(serialization, context); }
大概大家也可以猜出来，这是个自定义的异常处理类，辅助进行一些特定情况下的异常处理。问题很简单，而且并不影响使用，但是既然提示了就一定是个隐患，我也没当回事儿，就改了一下：
public override void GetObjectData(SerializationInfo serialization, StreamingContext context) { serialization.AddValue("Prompt", Prompt); base.GetObjectData(serialization, context); }
显示实现改为了隐式实现，分析结果正常了，由于代码分析时间比较长，我就往上下扫了一眼，发现不对劲，先不说显式实现接口方法可读性好，能清晰分出方法的归属，关键是这方法就不需要public，这两点瞬间就让我十分别扭，那就先改回去，细看看提示，是什么问题。
提示的字面意思很清楚，这个方法需要加个virtual关键字，让它可重写，显式实现可重写会是什么效果呢，这方法本身就不可见，这明显就是矛盾。不过转念一想，阴阳不衡方能三生万物，矛盾就是事物的一体两面，DDD书上说将矛盾统一起来是发现深层模型的一个途径。
怎么统一呢，其实这就很简单了，既然不想让它可见，不想让它被重写，那就是说它是不可被继承的，点开错误提示的详细信息，有两句话：
•该类型继承但并不重写 ISerializable.GetObjectData 方法，且该类型声明的实例字段没有使用 System.NonSerializedAttribute 特性进行标记。 •该类型没有密封，并且实现了外部不可见且不能重写的 GetObjectData 方法。
第一句明显和这没什么关系，第二句正好指明了问题的关键，改类型没有被密封，也就是说，既然想不让它可见就应该把它密封起来。所以，只要在类上加上sealed关键字禁止类被继承，这个矛盾就不存在了。
其实这是一个很小的问题，以至于平时VS都不愿意搭理，连警告都不发一个，但是这种细小的地方往往是滋养严重BUG的温床，废了这么大篇幅其实主要是想说，代码真正想写好，需要精益求精，认真对待，往往工作了几年后的程序员会认为代码就是体力活，遵守了开发规范就够了，但其实不然，写代码是门艺术，每一次写代码都是一次创作，当能在写完代码的时候感觉到心情舒畅，才算是入门，这之后还需要不断的思考创作。我一直以为，面向对象的开发其实就是拥抱生活，面向对象的设计建模及开发实现也就是人的世界观、价值观在特定业务场景中的展现，是对思维的一次梳理。。。似乎跑题了。
说这么多，其实只是因为走神，然后敲顺手了，顺便把一个小错误变得高大上一点，咱也瞬间显得提高了点层次，此致。