摘要：
封装集合：将集合中的某些方法封装起来，这些方法一般会牵扯到其他的逻辑。 举例理解：比如你给一个List<T>里面加一个对象的同时，可能还有一个计数器在计算List中对象的个数，我们不用暴露计数器，这样List.Add()和List.Remove()我们就可以封装起来了。 项目实例：我记得我有个项目需要不断的从数据库中读取User的Guid然后狂发Mail。开始的想法很简单，根据Window ID 去 CorpDirectory 抓Guid和Mail Address就好了。实际情况也就这么简单，但是后来Debug的时候发现程序很慢，弄了半天终于发现是这个抓Guid和Mail的动作太慢 阅读全文
摘要：
5.提取主类：提取一个基类，抽象出共有方法，比较常用的重构，这里的基类也许并不存在，需要自己新建立。 用法场景：当有一个类中的某个方法需要经常被其他的类调用的时候，说明这个方法重用率很高，可以考虑把它抽象出来，放到一个基类中。//重构前publicclass Dog{ publicvoid EatFood() { // eat some food } publicvoid Groom() { // perform grooming }}//重构后publicclass Animal{ ... 阅读全文
摘要：
本文主要讲几个涉及到继承方面的重构，继承一般会涉及到抽象类，接口，我们通常把有相似Func的类提取同类项，也就是抽象出接口或者抽象类；这样做的好处不言而喻，可以方便的扩展，修改，维护子类的共有方法，属性，索引等等。使用基类不仅仅是把各个子类联系起来了，更是降低了各个子类间的耦合度，再次体现了面向接口、继承编程的思想。 1.提升方法：指将方法向继承链的上层迁移的过程。 用法场景：当子类A中的一个方法需要被多个子类调用的时候，需要把这个方法提升到基类中，而不能让其它的子类都去Call子类A中的这个方法。这样做唯一的缺点是扩充了基类的接口、增加了其复杂性，因此需谨慎使用。只有当一个以上的子类需... 阅读全文
摘要：
概念：本文中的”使用多态代替条件判断”是指如果你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。正文：本文展示了面向对象编程的基础之一“多态性”， 有时你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。如下代码所示，OrderProcessor类的ProcessOrder方法根据Customer的类型分别执行一些操作，正如上面所讲的那样，我们最好将OrderProcessor类中这些算法（数据或操作）封装在特定的Customer 子类中。using System;using 阅读全文
摘要：
概念： 本文中的”尽快返回”是指把原来复杂的条件判断等语句用尽快返回的方式简化代码。正文：如首先声明的是前面讲的”分解复杂判断“，简单的来说，当你的代码中有很深的嵌套条件时，花括号就会在代码中形成一个长长的箭头。我们经常在不同的代码中看到这种情况，并且这种情况也会扰乱代码的可读性。下代码所示，HasAccess方法里面包含一些嵌套条件，如果再加一些条件或者增加复杂度，那么代码就很可能出现几个问题：1，可读性差 2，很容易出现异常 3，性能较差using System.Collections.Generic;using System.Linq;using LosTechies.DaysOfRef 阅读全文
摘要：
概念：本文中的”去除中间人对象”是指把 在中间关联而不起任何其他作用的类移除，让有关系的两个类直接进行交互。正文：有些时候在我们的代码会存在一些”幽灵类“，设计模式大师Fowler称它们为“中间人”类，“中间人”类除了调用别的对象之外不做任何事情，所以“中间人”类没有存在的必要，我们可以将它们从代码中删除，从而让交互的两个类直接关联。如下代码所示，Consumer类要得到AccountDataProvider的数据，但中间介入了没起任何作用的AccountManager类来关联，所以我们应当移除。using LosTechies.DaysOfRefactoring.PullUpField.Af 阅读全文
摘要：
概念：本文中的”为布尔方法命名”是指如果一个方法带有大量的bool参数时，可以根据bool参数的数量，提取出若干个独立的方法来简化参数。正文：我们现在要说的重构并不是普通字面意义上的重构，它有很多值得讨论的地方。当一个方法带有大量的bool参数时，会导致方法很容易被误解并产生非预期的行为，根据布尔型参数的数量，我们可以决定提取出若干个独立的方法来。具体代码如下：using LosTechies.DaysOfRefactoring.BreakResponsibilities.After;namespace LosTechies.DaysOfRefactoring.SampleCode.Renam 阅读全文
摘要：
概念：本文中的”去除上帝类”是指把一个看似功能很强且很难维护的类，按照职责把自己的属性或方法分派到各自的类中或分解成功能明确的类，从而去掉上帝类。正文：我们经常可以在一些原来的代码中见到一些类明确违反了SRP原则（单一原则），这些类通常以“Utils”或“Manager”后缀结尾，但有时这些类也没有这些特征，它仅仅是多个类多个方法的组合。另一个关于上帝类的特征是通常这些类中的方法被用注释分隔为不同的分组。那么久而久之，这些类被转换为那些没有人愿意进行归并到合适类的方法的聚集地，对这些类进行重构是将类中的代码按照职责分派到各自的类中，这样就解除了上帝类，也减轻了维护的负担。using Syste 阅读全文
摘要：
概念：本文中的”避免双重否定”是指把代码中的双重否定语句修改成简单的肯定语句，这样即让代码可读，同时也给维护带来了方便。正文：避免双重否定重构本身非常容易实现，但我们却在太多的代码中见过因为双重否定降低了代码的可读性以致于非常让人容易误解真正意图。存在双重否定的代码具有非常大的危害性，因为这种类型的代码容易引起错误的假设，错误的假设又会导致书写出错误的维护代码，最终会导致bug产生。具体可以看下面的代码：using System.Collections.Generic;using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.Aft.. 阅读全文
摘要：
概念：本文中的”引入契约式设计”是指我们应该对应该对输入和输出进行验证，以确保系统不会出现我们所想象不到的异常和得不到我们想要的结果。正文：契约式设计规定方法应该对输入和输出进行验证，这样你便可以保证你得到的数据是可以工作的，一切都是按预期进行的，如果不是按预期进行，异常或是错误就应该被返回，下面我们举的例子中，我们方法中的参数可能会值为null的情况，在这种情况下由于我们没有验证，NullReferenceException异常会报出。另外在方法的结尾处我们也没有保证会返回一个正确的decimal值给调用方法的对象。using System;using System.Collections. 阅读全文