重构11-20

11.提取父类

提取父类：即将一个类的基本属性，方法提取出来，封装在一个父类中，减少子类的代码，也可以将父类的代码共享给其他实现类。
eg:

public class Dog
    {
        public void EatFood()
        {
            // eat some food
        }


        public void Groom()
        {
            // perform grooming
        }
    }

重构：提取了Animal 方法来封装公用的EatFood和Groom类，从而使其他继承了Animal 类的子类都可以使用这两个方法了。

public class Animal
    {
        public void EatFood()
        {
            // eat some food
        }

        public void Groom()
        {
            // perform grooming
        }
    }

    public class Dog : Animal
    {
    }

总结：这个重构是典型的继承用法，很多程序员都会选择这样做，但是要注意正确的使用，不要造成过度使用了继承，如果过度使用了，请考虑用接口、组合和聚合来实现。

12.使用条件判断代替异常

使用条件判断代替异常：是指没有必要使用的异常做判断的条件改为条件判断。
eg:微波炉发动机在加热方法启动后，抛出了一个发动机有可能已经在加热的异常。

//微波炉
class Microwave
{
    private MicrowaveMotor motor=new MicrowaveMotor();
    //开始加热
    public boolean start(String food)
    {   
        boolean foodCooked=false;//还没熟

            try {
                motor.cook(food); //加热
                foodCooked=true;  //已熟
            } catch (InUseException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
                foodCooked=false;
            }


        return foodCooked;
    }
}
//微波炉发动机
class MicrowaveMotor
{
   private boolean inUse=false;
   public void cook(String food) throws InUseException
   {
       if (inUse)
           throw new InUseException();
       System.out.println(food+"在加热中。。。");   
   }
}

class InUseException extends Exception
{  
    private String msg;
    public InUseException() {
        // TODO Auto-generated constructor stub
        msg="微波炉发动机在使用中。。。";
    }
}

重构：将try-catch 语句改成if-return语句，简化书写，有提高性能。

//微波炉
class Microwave
{
    private MicrowaveMotor motor=new MicrowaveMotor();
  //开始加热
    public boolean start(String food)
    {   
        if(motor.isInuse())
            return false;
            motor.cook(food); //加热
        return true;
    }
}
//微波炉发动机
class MicrowaveMotor
{
 private boolean inUse=false;
 public boolean isInuse()
 {
     return inUse;
 }
 public void cook(String food)  
 {

       System.out.println(food+"在加热中。。。");   
 }
}

总结：本来用异常来做cook方法是否出现错误的判断，改成用条件方式提前预判错误是否发生。

13.提取工厂类

提取工厂类(抽象工厂模式)：当一个类(Controller)负责多种对象创建时,则内部的代码量会特别多，此时可以应用抽象工厂模式为Controller类提供抽象工厂接口，根据其不同的工厂实现类传入，创建不同的对象。
eg:CarController类将所有车型的创建封装在该类的内部，变得累赘，不容易维护

//生产车控制器：负责多种车型的创建
class CarController
{
    public Car create(String name,double speed)
    {
        Car car=new Car(name, speed);
        return car;
    }
}
class Car
{
    private String name;
    private double speed;
    public Car(String name,double speed) {
        // TODO Auto-generated constructor stub
       this.name=name;
       this.speed=speed;
    }
}

重构:抽象出一个工厂接口，根据传入不同的工厂接口实现类，创建不同的车型。

//生产车控制器：根据传入的抽象工厂接口，创建不同的车型
class CarController
{  
    private ICarFactory iCarFactory;
    public CarController(ICarFactory iCarFactory) {
        // TODO Auto-generated constructor stub
        this.iCarFactory=iCarFactory;

    }
    public Car create(String name,double speed)
    {
        return iCarFactory.create(name,speed);
    }
}
interface ICarFactory
{
       Car create(String name, double speed);
}
class FordFactory implements ICarFactory
{   
     @Override
    public Car create(String name, double speed) {
        // TODO Auto-generated method stub
        Car car=new Car(name, speed);
        car.setType("Ford");
        return car;
    }
}
class Car
{
    private String name;
    private double speed;
    private String type;
    public String getType() {
        return type;
    }
    public void setType(String type) {
        this.type = type;
    }
    public Car(String name,double speed) {
        // TODO Auto-generated constructor stub
       this.name=name;
       this.speed=speed;
    }
}

14.提取子类

提取子类：将父类中多余的操作移到子类中进行操作。
eg:当你的基类中存在一些方法不是所有的子类都需要访问，你想将它们调整到子类中时，这个重构会变得很有用了。如下代码所示，我们需要一个 Registration类用来处理学生选课的信息。但是当Registration类开始工作后，我们意识到我们会在两种不同的上下文中使用Registration类，NonRegistrationAction和Notes只有在我们处理未注册情况下才用到。
所以我们将NonRegistration和Notes提到单独的NonRegistration类中。

public class Registration
    {
        public NonRegistrationAction Action { get; set; }
        public decimal RegistrationTotal { get; set; }
        public string Notes { get; set; }
        public string Description { get; set; }
        public DateTime RegistrationDate { get; set; }
    }

重构：重构后的代码如下所示，这样也满足面向对象五大原则之一的单一职责。同时也让类的结构变得更加清晰，增强了可维护性。

public class Registration
    {
        public decimal RegistrationTotal { get; set; }
        public string Description { get; set; }
        public DateTime RegistrationDate { get; set; }
    }

    public class NonRegistration : Registration
    {
        public NonRegistrationAction Action { get; set; }
        public string Notes { get; set; }
    }

总结：这个重构方法经常用来规范类的职责，和之前的一些重构方法也有些类似。

15.合并继承

合并继承：是指如果子类的属性和方法也适合于基类，那么就可以移除子类，从而减少依赖关系。
eg:“合并继承”重构一般用在当我们觉得不需要子类的时候。
如下代码所示，StudentWebSite子类除了有一个属性用来说明网站是否是活动的外没有别的责任，在这种情形下我们意识到IsActive属性可以应用到所有的网站，所以我们可以将IsActive属性上移到基类中，并去掉StudentWebSite类。

 public class Website
    {
        public string Title { get; set; }
        public string Description { get; set; }
        public IEnumerable<Webpage> Pages { get; set; }
    }

    public class StudentWebsite : Website
    {
        public bool IsActive { get; set; }
    }

重构：

 public class Website
    {
        public string Title { get; set; }
        public string Description { get; set; }
        public IEnumerable<Webpage> Pages { get; set; }
        public bool IsActive { get; set; }
    }

总结：这篇和上篇其实最主要论述了子类和父类的继承关系以及如何判断什么时候需要使用继承，一般我们都能处理好这些关系，所以相对比较简单。

16.分解方法

分解方法：是指把我们所做的这个功能不停的分解方法，直到将一个大方法分解为名字有意义且可读性更好的若干个小方法。与“提取方法”和“提取方法对象”如出一辙，尤其是“提取方法”，所以大家只要知道用这种思想重构就行。

17.引入参数对象

引入参数对象：对于某个的方法的参数特别多的时候，我们可以将这些参数封装成一个对象，再将该对象传入方法。
eg:如果某个方法的参数大于5个时，由于过长可以将它封装成一个对象传入进行。

class Registration
{
    public void create(String name,int age,double score, char sex)
    {
        //do work
    }
}

重构：将方法的参数封装到一个RegistrationInfo类中。

class Registration
{

    public void create(RegistrationInfo registInfo)
    {
        //do work
    }
}
class RegistrationInfo
{
    String name ;
    int age;
    double score;
    char sex;
}

总结：这种重构很重要，尤其是当一个方法的参数比较多的时候，不管是大中型项目还是小型项目，都会遇到这种场景，所以建议大家多使用这个重构。这种封装的思想在SOA 里面也经常运用到，封装输入Message，封装输出Message，消息来和消息去以及消息间的交互就构成了整个应用体系。

18.分解复杂判断

分解复杂判断：当条件关系存在嵌套多个条件时，应当用“尽快返回”(最重要的条件放在最前面)的方式简化代码。与“封装条件”类似，但是“封装条件”考虑的是单条的判断里涉及复杂的判断和参数多少。
eg:

class User
{
    private String userName;
    private String passWord;
    private int id;
    public boolean logining()
    {   
        //多重条件嵌套关系
         if(id==2011120255)
         {
             if(passWord.equals("123"))
             {
                 if (userName.equals("hq"))
                 {
                     return true;
                 }
             }
         }
         return false;
    }
}

重构：

class User
{
    private String userName;
    private String passWord;
    private int id;

    public boolean logining()
    {   
          //将最可能出错的条件，最重要的条件放在前面，达到尽早返回的目的。
          if(userName==null || passWord==null)
              return false;

             if(passWord.equals("hq"))
             {
                 if (userName.equals("123"))
                 {
                     if(id==2011120255)
                         return true;
                 }
             }

         return false;
    }
}

总结：这个重构很重要，它和后面讲的”尽快返回“有些类似，我们在做复杂的处理过程时，要经常考虑这个重构，用好了它，会对我们的帮助很大。

19.引入契约式设计

引入契约式设计：对输入和输出的参数进行验证，确保对各种错误异常的有相应的处理，让用户便于查找错误的源头。
eg:契约式设计规定方法应该对输入和输出进行验证，这样你便可以保证你得到的数据是可以工作的，一切都是按预期进行的，如果不是按预期进行，异常或是错误就应该被返回，下面我们举的例子中，我们方法中的参数可能会值为null的情况，在这种情况下由于我们没有验证，NullReferenceException异常会报出。另外在方法的结尾处我们也没有保证会返回一个正确的decimal值给调用方法的对象。

 public class CashRegister
    {
        public decimal TotalOrder(IEnumerable<Product> products, Customer customer)
        {
            decimal orderTotal = products.Sum(product => product.Price);

            customer.Balance += orderTotal;

            return orderTotal;
        }
    }

重构：对上面的代码重构是很简单的，首先我们处理不会有一个null值的customer对象，检查我们最少会有一个product对象。在返回订单总和之前先确保我们会返回一个有意义的值。如果上面说的检查有任何一个失败，我们就抛出对应的异常，并在异常里说明错误的详细信息，而不是直接抛出NullReferenceException。

 public class CashRegister
    {
        public decimal TotalOrder(IEnumerable<Product> products, Customer customer)
        {
            if (customer == null)
                throw new ArgumentNullException("customer", "Customer cannot be null");
            if (products.Count() == 0)
                throw new ArgumentException("Must have at least one product to total", "products");

            decimal orderTotal = products.Sum(product => product.Price);

            customer.Balance += orderTotal;

            if (orderTotal == 0)
                throw new ArgumentOutOfRangeException("orderTotal", "Order Total should not be zero");

            return orderTotal;
        }
    }

总结：上面的代码中添加了额外的代码来进行验证，虽然看起来代码复杂度增加了，但我认为这是非常值得做的，因为当NullReferenceException发生时去追查异常的详细信息真是很令人讨厌的事情。微软在处理代码乃至产品的时候，很喜欢应用此重构，你如果认真看它的代码库，认真看一下WCF的设计，就不难发现了。这个重构建议大家经常使用，这会增强整个系统的稳定性和健壮性。

20.避免双重否定

避免双重否定：即避免在条件语句里使用“！”，多用肯定语句，这样的代码会更加容易理解。
eg:

public class  Order
    {
        public void  Checkout(IEnumerable<Product> products, Customer  customer)
        {
            if  (!customer.IsNotFlagged)
            {
                // the customer account is flagged
                // log some errors and return
                return;
            }

            // normal order processing
        }
    }

    public class  Customer
    {
        public decimal  Balance { get; private set; }

        public bool  IsNotFlagged
        {
            get  { return  Balance < 30m; }
        }
    }

重构：如上代码中的双重否定可读性非常低，因为我们很难搞明白双重否定的正确值。要重构它也非常容易，如下是重构后的代码：

public class Order
    {
        public void Checkout(IEnumerable<Product> products, Customer customer)
        {
            if (customer.IsFlagged)
            {
                // the customer account is flagged
                // log some errors and return
                return;
            }

            // normal order processing
        }
    }

    public class Customer
    {
        public decimal Balance { get; private set; }

        public bool IsFlagged
        {
            get { return Balance >= 30m; }
        }
    }

总结：”双重否定“很容易让人产生错误的判断，也很难让人理解你的代码，所以这个重构在我们的代码中是很重要的，尤其是在判断条件很多且业务复杂的时候。