C#动态表达式计算
应该有不少人开发过程中遇到过这样的需求，我们直接看图说话：
如上图所示，其中Entity为实体类，其中包括五个属性，该五个属性的值分别来自于数据库查询结果；
用户通过可视化界面进行某些条件的配置以及某些算法的配置并自动生成表达式或者生成数学模型；
程序中需要通过生成的表达式以及动态从数据库中获取的数据进行算法映射以及自动计算出结果。
该需求这边可以举出几个应用场景：
1、报表设计器
我们可以通过报表设计器设计数据库的映射关系并配置数据之间的算法关系，然后动态生成报表；
2、某些采集工具
定向采集指定数据集合并根据某些动态配置的逻辑进行；
3、数据挖掘和分析
面对这样的需求我们如何实现？
我们需要开发表达式映射引擎和脚本执行引擎？
假如要实现，该如何设计该框架？下一章我将呈现我们的解决方案，这一章就先说这么多，大家也可以畅谈以下自己的想法，忙了。。。
代码的坏味道之三——译自《重构》
散弹式修改(Shotgun Surgery)
散弹式修改和发散式变化类似，但却相反。每当你做一种修改你却必须对很多不同的类做很多小的变化，你面临的就是散弹式修改。当变化到处都是时，有的变化就不好找到了，这样很容易漏掉重要的更改。
这种情况下你要使用移动方法（Move Method）和移动字段（Move Field）来把所有的变化放到一个类里。如果没有现成的类合适，就创建一个类。通常你会用到内联化类（Inline Class）把一系列行为放到一起。你会有一点发散式变化的问题，但你可以轻松处理它。
发散式变化是一个类经受多种种类的修改，散弹式修改是一处修改改变了很多类。两种情况你都希望重新组织，这样理想状态下一个普通变化和类有一对一的链接关系。
依恋情节（Feature Envy）
对象的意义就是他们在技术上是数据和处理数据的操作的打包。常见的问题是一个方法对其他类比对自己所在的类更有兴趣。最普遍的嫉妒的焦点就是数据。我们数不清多少次我们看到一个方法为了计算一个值调用了6，7个另一个对象的get方法。幸运的是解决之道是很显而易见的，这个方法显然应该归于别处，所以你用移动方法（Move Method）来达到目的。有时方法中只有一部分有依恋情节，这种情况下用提取方法处理有依恋的部分，用移动方法来给他一个理想的归宿。
当然不是所有的情况都可以一刀切。通常一个方法使用若干类的特性，那么我们应该把他归于哪一个类呢？我们用的启示是取决于哪一个类中有大多数的数据，那么就把方法放在数据一起。如果已经使用提取方法来把方法分解成若干分离的部分，这一步可以做的轻松一些。
当然有一些精妙的模式会打破这一规矩。来自“*”（Gang of Four）策略和访问者马上就浮现在脑海。Kent Beck的自委托是另一个例子。你用这些模式模式来处理发散式修改。最基本的规则是把一起修改的东西放在一起。数据和引用数据的行为经常一起修改，但也有例外。当例外出现时，我们把行为移动使变化保持在一个地方。策略和访问者模式允许你更容易的改变行为，因为他们以进一步的重定向为代价，隔离了一小部分需要倍覆盖的行为。
数据泥团（Data Clumps）
数据对象像小孩一样，他们喜欢聚在一群到处游荡。你常常会看到同样的三，四个数据对象一起出现在很多地方：一些类中的字段，一些方法签名里的参数。一簇到处都是的数据真的需要被放在他们自己的对象里。第一步是寻找在哪这些数据表现为字段。对这些字段用提取类把一簇转变为一个对象。然后把你的注意力转移到方法的签名上，用引入参数对象后者保全整个对象来缩减他们。马上带来的好处是你缩减了很多参数列表简化了方法的调用。不用为数据团只用了新对象的部分字段担心。只要你用两个或更多的字段替换为新的对象，你会进步的。
一个好的测试是考虑删除一个数据的值：如果你这样做其它数据是否还有意义？如果没有，这就是一个明确的信号告诉你要新建一个对象了。
减小字段列表和参数列表很明显会移除一些坏味道，但一旦当你有了这些对象时，你就拥有制造好味道的机会了。现在你可以寻找依恋情节的例子，那意味着行为可以被加入你的新类里。不久这些类就会成为社群中的高效成员。