http://www.cnblogs.com/zenghongliang/archive/2010/06/28/1766436.html这是原文地址
这里仅仅是做了个总结，相当于速查手册。
1、对集合封装
集合，比如List<XXX> ，如果做为返回值，那也就把其自身所拥有的Add，Remove等方法暴漏了出去。如果对于调用方，仅仅是对其暴露展示功能，可以进行如下封装：
private List<OrderLine> _orderLines;
public IEnumerable<OrderLine> OrderLines
{
get { return _orderLines; }
}
它只包含一个GetEnumerator()方法。
2、移动方法
移动方法是一个很简单也很常见的重构，只要是系统就会存在很多类，那么类里面包括很多方法，如果一个方法经常被另外一个类使用（比本身的类使用还多）或者这个方法本身就不应该放在这个类里面，那么这个适合应该考虑把它移到合适的类中。
点评：以上是原文，个人观点，这个概念真的不是这么表象。众所周知，我们的程序，为什么分层？数据层、逻辑层、UI层、Common....
为了结构清晰、为了复用，为了扩展方便等等诸多理由
如果真如作者所说，那我们岂不是又回到从前了吗？
这个也就是仅仅针对于个别局部方法（套用了局部变量和全局变量的概念）适用罢了。
3、提升方法
提升方法是指将一个很多继承类都要用到的方法提升到基类中。这个重构要根据具体情况使用，如果不是每个子类都有这个方法的话，可以考虑使用接口或者其他方式。
点评：接口也未必能行，如果不是每个子类都有这个方法，那接口一旦定义了，就要在这些不相干的子类中进行“假实现”。
还是没太理解作者的想法。因为这种行为，对于大多数人来说，是肯定会用的，毕竟避免重复代码的引申义就是减少工作量嘛。
后来看到一个回复，说的比较好：这个重构要根据具体情况使用，如果不是每个子类都有这个方法的话，可以考虑使用接口或者其他方式。
4、下降方法
同时如果在父类Animal 中如果没有其他的字段或者公用方法的话，可以考虑把Bark方法做成一个接口，从而去掉Animal 类。
点评：这个真不敢完全认同了。我如果这样做了，我就要对外即公布接口，又公布具体实现类，为了一点的优化而改变了设计结构，得不偿失的感觉。
原文地址：http://www.cnblogs.com/KnightsWarrior/archive/2010/06/28/1766583.html
5、提升字段
把子类公用的字段提升到基类中，从而达到公用的目的。这样提的前提是这些子类有一个基类或者有很多相似的字段和方法，不然为了一个字段而单独建立一个抽象类是不可取的，所以这个就需要具体权衡。
点评：这个可以有，经常用到。
6、降低字段
本文中的降低字段和前篇的提升字段正好相反，就是把基类中只有某些少数类用到的字段降低到使用它们的子类中。
这样做的好处可以简化基类，同时让其他没有使用它的子类也变得更加简单，如果这样的字段比较多的话，使用此重构也能节约一部分内存。
7、重命名
改名（方法，类，参数）是指在写代码的时候对类、方法、参数、委托、事件等等元素取一个有意义的名称
点评：这个的确如此。有时候在做项目时，感觉这个起名，真不是意见简单的事，既要让自己明白，还要让别人明白，照顾各方面。长了不行，短了也有问题。诸如此类，流汗。
8、 使用委派代替继承
本文中的“使用委派代替继承”是指在根本没有父子关系的类中使用继承是不合理的，可以用委派的方式来代替。