aspnetwinform

31天重构学习笔记重新整理下载

前言

前两天写了一篇程序猿也爱学英语（上），有图有真相的文章，写作那篇文章只是自己一时兴起，或者说是自己的兴趣使然。文中的观点只是自己的学习心得和体会，属一家之言且鉴于本人不是学英语出身，所以也肯定有不正确的地方，也欢迎大家积极讨论并给我留言，再次感谢大家的热烈支持。关于大家询问下篇的发布问题，我想我会尽力在周末完成。

这几天由于刚发布完项目，所以有比较充裕的时间整理自己的知识库，发现三年多以前学习并记录了31天重构系列笔记，至今仍回味无穷，索性重新阅读、纠正错误并重新排版整理出来，希望再次和大家一起分享。

对31天重构系列文章最早接触是在2009年10月份，由于当时没有订阅Sean Chambers的 blog，所以是在国外的社区上闲逛的时候链接过去的。基于文章中的重构点都比较常用，所以一口气看完了整个系列，同时由于这些重构Tips基本上项目都在使用，只是我们没有专门把它标示和整理出来，所以当时也没有引起多大的重视。

但就在三年前，当时我们在做一个WPF的重构项目且鉴于团队成员技术和经验参差不齐，非常必要专门整理一个重构的纲要，所以就收集和整理了很多的资料（31天重构也在其中）。当然这个系列除了用语重构Tips之外，也非常适合做新系统的代码规范参考。总而言之：只要有代码的地方，这个重构规范就很有价值。同时鉴于当时自己刚到新加坡这个美丽的城市，没有亲戚或者朋友，周末也不想出去闲逛，所以才静下心来用了足足两天时间学习并写完了这个系列笔记。

31天重构这个系列和《代码大全》、《重构：改善既有代码的设计》比较起来最大的特点就是比较简单且浅显易懂。我这系列文章也都是学习并概括Sean Chambers的31天重构的知识要领，所以如果大家对这个笔记有任何的问题或者异议也可以指出，或者大家可以直接去看原文（即可掌握了技术，又可以学习英语！）：

http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx。

代码下载地址：http://github.com/schambers/days-of-refactoring

1. 封装集合

概念：本文所讲的封装集合就是把集合进行封装，只提供调用端需要的接口。

正文：在很多时候，我们都不希望把一些不必要的操作暴露给调用端，只需要给它所需要的操作或数据就行，那么做法就是封装。这个重构在微软的代码库也经常遇到。比如最经典的属性对字段的封装就是一个很好的例子，那么下面我们将看到对集合的封装，如下代码所示，调用端只需要一个集合的信息，而我们则提供了一个IList的集合，大家都知道IList具有对集合的所有操作，所以这会带来很多隐患，最好的做法就是对它进行重构。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.EncapsulateCollection.Before
{
    public class Order
    {
        private List<OrderLine> _orderLines;
        private double _orderTotal;

        public IList<OrderLine> OrderLines
        {
            get { return _orderLines; }
        }

        public void AddOrderLine(OrderLine orderLine)
        {
            _orderTotal += orderLine.Total;
            _orderLines.Add(orderLine);
        }

        public void RemoveOrderLine(OrderLine orderLine)
        {
            orderLine = _orderLines.Find(o => o == orderLine);

            if (orderLine == null)
                return;

            _orderTotal -= orderLine.Total;
            _orderLines.Remove(orderLine);
        }
    }

    public class OrderLine
    {
        public double Total { get; private set; }
    }
}

那么重构之后，我们把IList换成了IEnumerable，大家都知道只包括一个返回值为IEnumerator的GetEnumerator()方法，所以这样只能遍历取出它的值，而不能对这个集合做出改变，这正是我们所需要的结果，具体代码如下：

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.EncapsulateCollection.After
{
    public class Order
    {
        private List<OrderLine> _orderLines;
        private double _orderTotal;

        public IEnumerable<OrderLine> OrderLines
        {
            get { return _orderLines; }
        }

        public void AddOrderLine(OrderLine orderLine)
        {
            _orderTotal += orderLine.Total;
            _orderLines.Add(orderLine);
        }

        public void RemoveOrderLine(OrderLine orderLine)
        {
            orderLine = _orderLines.Find(o => o == orderLine);

            if (orderLine == null)
                return;

            _orderTotal -= orderLine.Total;
            _orderLines.Remove(orderLine);
        }
    }

    public class OrderLine
    {
        public double Total { get; private set; }
    }
}

总结：这个例子很容易让我们想到以前系统间耦合常喜欢用数据库。每个系统都会操作数据库，并且有些系统还会对数据库的表结构或字段进行修改，那么这很容易就会造成维护的地狱，很明智的一个做法就是使用SOA来隔开这些耦合，让一些只需要数据展示的系统得到自己需要的数据即可。

2. 移动方法

概念：本文所讲的移动方法就是方法放在合适的位置（通常指放在合适的类中）。

正文：移动方法是一个很简单也很常见的重构，只要是系统就会存在很多类，那么类里面包括很多方法，如果一个方法经常被另外一个类使用（比本身的类使用还多）或者这个方法本身就不应该放在这个类里面，那么这个适合应该考虑把它移到合适的类中。代码如下：

namespace LosTechies.DaysOfRefactoring.MoveMethod.Before
{
    public class BankAccount
    {
        public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest) 
        { 
            AccountAge = accountAge; 
            CreditScore = creditScore; 
            AccountInterest = accountInterest; 
        }

        public int AccountAge { get; private set; }
        public int CreditScore { get; private set; }
        public AccountInterest AccountInterest { get; private set; }

        public double CalculateInterestRate()
        {
            if (CreditScore > 800)
                return 0.02;

            if (AccountAge > 10)
                return 0.03;

            return 0.05;
        }
    }

    public class AccountInterest
    {
        public BankAccount Account { get; private set; }

        public AccountInterest(BankAccount account)
        {
            Account = account;
        }

        public double InterestRate
        {
            get { return Account.CalculateInterestRate(); }
        }

        public bool IntroductoryRate
        {
            get { return Account.CalculateInterestRate() < 0.05; }
        }
    }
}

移动以后大家可以看到BankAccount类的职责也单一，同时CalculateInterestRate也放到了经常使用且适合它的类中了，所以此重构是一个比较好的重构，能让整个代码变得更加合理。

namespace LosTechies.DaysOfRefactoring.MoveMethod.After
{
    public class AccountInterest
    {
        public BankAccount Account { get; private set; }

        public AccountInterest(BankAccount account)
        {
            Account = account;
        }

        public double InterestRate
        {
            get { return CalculateInterestRate(); }
        }

        public bool IntroductoryRate
        {
            get { return CalculateInterestRate() < 0.05; }
        }

        public double CalculateInterestRate()
        {
            if (Account.CreditScore > 800)
                return 0.02;

            if (Account.AccountAge > 10)
                return 0.03;

            return 0.05;
        }
    }
}

namespace LosTechies.DaysOfRefactoring.MoveMethod.After
{
    public class BankAccount
    {
        public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest)
        {
            AccountAge = accountAge;
            CreditScore = creditScore;
            AccountInterest = accountInterest;
        }

        public int AccountAge { get; private set; }
        public int CreditScore { get; private set; }
        public AccountInterest AccountInterest { get; private set; }
    }
}

总结：这个重构法则在很多时候能让我们把代码组织的结构调整得更合理，同时也能给以后的维护带来方便。

3. 提升方法

概念：提升方法是指将一个很多继承类都要用到的方法提升到基类中。

正文：提升方法是指将一个很多继承类都要用到的方法提升到基类中，这样就能减少代码量，同时让类的结构更清晰。如下代码所示，Turn方法在子类Car 和Motorcycle 都会用到，因为Vehicle 都会有这个方法，所以我们就会想到把它提到基类中。

namespace LosTechies.DaysOfRefactoring.PullUpMethod.Before
{
    public abstract class Vehicle
    {
        // other methods
    }

    public class Car : Vehicle
    {
        public void Turn(Direction direction)
        {
            // code here
        }
    }

    public class Motorcycle : Vehicle
    {
    }

    public enum Direction
    {
        Left,
        Right
    }
}

重构后的代码如下，那么现在Car 和Motorcycle 都具有Turn这个方法，如果这个方法修改也只需要修改基类即可，所以给维护和以后的重构带来了方便。

namespace LosTechies.DaysOfRefactoring.PullUpMethod.After
{
    public abstract class Vehicle
    {
        public void Turn(Direction direction)
        {
            // code here
        }
    }

    public class Car : Vehicle
    {
    }

    public class Motorcycle : Vehicle
    {
    }

    public enum Direction
    {
        Left,
        Right
    }
}

总结：这个重构要根据具体情况使用，如果不是每个子类都有这个方法的话，可以考虑使用接口或者其他方式。

4. 降低方法

概念：本文中的降低方法和前篇的提升方法整好相反，也就是把个别子类使用到的方法从基类移到子类里面去。

正文：如下代码所示，Animal 类中的方法Bark只有在其子类Dog 中使用，所以最好的方案就是把这个方法移到子类Dog 中。

namespace LosTechies.DaysOfRefactoring.PushDownMethod.Before
{
    public abstract class Animal
    {
        public void Bark()
        {
            // code to bark
        }
    }

    public class Dog : Animal
    {
    }

    public class Cat : Animal
    {
    }
}

重构后的代码如下，同时如果在父类Animal 中如果没有其他的字段或者公用方法的话，可以考虑把Bark方法做成一个接口，从而去掉Animal 类。

namespace LosTechies.DaysOfRefactoring.PushDownMethod.After
{
    public abstract class Animal
    {
    }

    public class Dog : Animal
    {
        public void Bark()
        {
            // code to bark
        }
    }

    public class Cat : Animal
    {
    }
}

总结：面向对象三大特征（继承、封装、多态）很多时候可以帮助我们，但同时也可能会造成使用过度或者使用不当，所以如何把握好设计，这个就变得至关重要。在什么时候使用继承的方式，在什么时候使用组合和聚合，接口和继承类的选择等久成了我们的重点。

5. 提升字段

概念：本文中的提升字段和前面的提升方法颇为相似，就是把子类公用的字段提升到基类中，从而达到公用的目的。

正文：如下代码所示， Account 的两个子类CheckingAccount 和SavingsAccount 都有minimumCheckingBalance 字段，所以可以考虑把这个字段提到基类中。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace LosTechies.DaysOfRefactoring.PullUpField.Before
{
    public abstract class Account
    {
    }

    public class CheckingAccount : Account
    {
        private decimal _minimumCheckingBalance = 5m;
    }

    public class SavingsAccount : Account
    {
        private decimal _minimumSavingsBalance = 5m;
    }
}

重构后的代码如下，这样提的前提是这些子类有一个基类或者有很多相似的字段和方法，不然为了一个字段而单独建立一个抽象类是不可取的，所以这个就需要具体权衡。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace LosTechies.DaysOfRefactoring.PullUpField.After
{
    public abstract class Account
    {
        protected decimal _minimumBalance = 5m;
    }

    public class CheckingAccount : Account
    {
    }

    public class SavingsAccount : Account
    {
    }
}

总结：这个重构的策略比较简单，同时也是比较常用的一些做法，最主要就是要注意权衡是否真的有这个必要，看这样做究竟有没有什么好处（比如只需要改一个地方，维护简便了，同时代码量也更少了等）。

6. 降低字段

概念：本文中的降低字段和前篇的提升字段正好相反，就是把基类中只有某些少数类用到的字段降低到使用它们的子类中。

正文：如下代码所示，基类Task 类中的_resolution字段只会在子类BugTask 中用到，所以就考虑把它放到BugTask 类中。

namespace LosTechies.DaysOfRefactoring.PushDownField.Before
{
    public abstract class Task
    {
        protected string _resolution;
    }

    public class BugTask : Task
    {
    }

    public class FeatureTask : Task
    {
    }
}

重构后的代码如下所示，这样做的好处可以简化基类，同时让其他没有使用它的子类也变得更加简单，如果这样的字段比较多的话，使用此重构也能节约一部分内存。

namespace LosTechies.DaysOfRefactoring.PushDownField.After
{
    public abstract class Task
    {
    }

    public class BugTask : Task
    {
        private string _resolution;
    }

    public class FeatureTask : Task
    {
    }
}

总结：此重构也是一个非常简单的重构，在很多时候我们都会不自觉的使用它。

7. 重命名（方法，类，参数）

概念：本文中的改名（方法，类，参数）是指在写代码的时候对类、方法、参数、委托、事件等等元素取一个有意义的名称。

正文：如下代码所示，加入一个公司建立一个员工的类，类中有一个员工名字的字段和一个按照小时计算员工收入的方法，那么下面代码的取名就显得很难理解了，所以我们会重构名称。

namespace LosTechies.DaysOfRefactoring.Rename.Before
{
    public class Person
    {
        public string FN { get; set; }

        public decimal ClcHrlyPR()
        {
            // code to calculate hourly payrate
            return 0m;
        }
    }
}

重构后代码如下所示，这样看起来就非常清晰，如果有新进项目组的成员，也会变得很乐意看这个代码。

namespace LosTechies.DaysOfRefactoring.Rename.After
{
    // Changed the class name to Employee
    public class Employee
    {
        public string FirstName { get; set; }

        public decimal CalculateHourlyPay()
        {
            // code to calculate hourly payrate
            return 0m;
        }
    }
}

总结：此重构经常被广大程序员所忽视，但是带来的隐患是不可估量的，也许老板要修改功能，那我们来看这段没有重构的代码（就算是自己写的，但由于时间和项目多等关系，我们也很难理解了），然后就会变得焦头烂额。相反重构后的代码就会觉得一目了然、赏心悦目。

8. 使用委派代替继承

概念：本文中的“使用委派代替继承”是指在根本没有父子关系的类中使用继承是不合理的，可以用委派的方式来代替。

如下代码所示，Child 和Sanitation （公共设施）是没有逻辑上的父子关系，因为小孩不可能是一个公共设施吧！所以我们为了完成这个功能可以考虑使用委派的方式。

namespace LosTechies.DaysOfRefactoring.ReplaceInheritance.Before
{
    public class Sanitation
    {
        public string WashHands()
        {
            return "Cleaned!";
        }
    }

    public class Child : Sanitation
    {
    }
}

重构后的代码如下，把Sanitation 委派到Child 类中，从而可以使用WashHands这个方法，这种方式我们经常会用到，其实IOC也使用到了这个原理，可以通过构造注入和方法注入等。

namespace LosTechies.DaysOfRefactoring.ReplaceInheritance.After
{
    public class Sanitation
    {
        public string WashHands()
        {
            return "Cleaned!";
        }
    }

    public class Child
    {
        private Sanitation Sanitation { get; set; }

        public Child()
        {
            Sanitation = new Sanitation();
        }

        public string WashHands()
        {
            return Sanitation.WashHands();
        }
    }
}

总结：这个重构是一个很好的重构，在很大程度上解决了滥用继承的情况，很多设计模式也用到了这种思想（比如桥接模式、适配器模式、策略模式等）。

9. 提取接口

概念：本文中的“提取接口” 是指超过一个的类要使用某一个类中部分方法时，我们应该解开它们之间的依赖，让调用者使用接口，这很容易实现也可以降低代码的耦合性。

正文：如下代码所示，RegistrationProcessor 类只使用到了ClassRegistration 类中的Create方法和Total 字段，所以可以考虑把他们做成接口给RegistrationProcessor 调用。

namespace LosTechies.DaysOfRefactoring.ExtractInterface.Before
{
    public class ClassRegistration
    {
        public void Create()
        {
            // create registration code
        }

        public void Transfer()
        {
            // class transfer code
        }

        public decimal Total { get; private set; }
    }

    public class RegistrationProcessor
    {
        public decimal ProcessRegistration(ClassRegistration registration)
        {
            registration.Create();
            return registration.Total;
        }
    }
}

重构后的代码如下，我们提取了一个IClassRegistration 接口，同时让ClassRegistration 继承此接口，然后调用端RegistrationProcessor 就可以直接通过IClassRegistration 接口进行调用。

namespace LosTechies.DaysOfRefactoring.ExtractInterface.After
{
    public interface IClassRegistration
    {
        void Create();
        decimal Total { get; }
    }

    public class ClassRegistration : IClassRegistration
    {
        public void Create()
        {
            // create registration code
        }

        public void Transfer()
        {
            // class transfer code
        }

        public decimal Total { get; private set; }
    }

    public class RegistrationProcessor
    {
        public decimal ProcessRegistration(IClassRegistration registration)
        {
            registration.Create();
            return registration.Total;
        }
    }
}

总结：这个重构策略也是一个常见的运用，很多设计模式也会在其中运用此思想（如简单工程、抽象工厂等都会通过接口来解开依赖）。

10. 提取方法

概念：本文中的把某些计算复杂的过程按照功能提取成各个小方法，这样就可以使代码的可读性、维护性得到提高。

正文：如下代码所示，CalculateGrandTotal方法里面包含了多个逻辑，第一计算subTotal 的总和，第二subTotal 要循环减去discount，也就是计算Discounts，第三就是计算Tax。所以我们可以根据功能把他们拆分成三个小方法。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.ExtractMethod.Before
{
    public class Receipt
    {
        private IList<decimal> Discounts { get; set; }
        private IList<decimal> ItemTotals { get; set; }

        public decimal CalculateGrandTotal()
        {
            decimal subTotal = 0m;
            foreach (decimal itemTotal in ItemTotals)
                subTotal += itemTotal;

            if (Discounts.Count > 0)
            {
                foreach (decimal discount in Discounts)
                    subTotal -= discount;
            }

            decimal tax = subTotal * 0.065m;

            subTotal += tax;

            return subTotal;
        }
    }
}

重构后的代码如下，然后CalculateGrandTotal方法就直接调用CalculateSubTotal、CalculateDiscounts、CalculateTax，从而是整个逻辑看起来更加清晰，并且可读性和维护性也得到了大大提高。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.ExtractMethod.After
{
    public class Receipt
    {
        private IList<decimal> Discounts { get; set; }
        private IList<decimal> ItemTotals { get; set; }

        public decimal CalculateGrandTotal()
        {
            decimal subTotal = CalculateSubTotal();

            subTotal = CalculateDiscounts(subTotal);

            subTotal = CalculateTax(subTotal);

            return subTotal;
        }

        private decimal CalculateTax(decimal subTotal)
        {
            decimal tax = subTotal * 0.065m;

            subTotal += tax;
            return subTotal;
        }

        private decimal CalculateDiscounts(decimal subTotal)
        {
            if (Discounts.Count > 0)
            {
                foreach (decimal discount in Discounts)
                    subTotal -= discount;
            }
            return subTotal;
        }

        private decimal CalculateSubTotal()
        {
            decimal subTotal = 0m;
            foreach (decimal itemTotal in ItemTotals)
                subTotal += itemTotal;
            return subTotal;
        }
    }
}

总结：这个重构在很多公司都有一些的代码规范作为参考，比如一个类不能超过多少行代码，一个方法里面不能超过多少行代码，这在一定程度上也能使程序员把这些复杂的逻辑剥离成意义很清楚的小方法。

11. 使用策略类

概念：本文中的“使用策略类” 是指用设计模式中的策略模式来替换原来的switch case和if else语句，这样可以解开耦合，同时也使维护性和系统的可扩展性大大增强。

正文：如下面代码所示，ClientCode 类会更加枚举State的值来调用ShippingInfo 的不同方法，但是这样就会产生很多的判断语句，如果代码量加大，类变得很大了的话，维护中改动也会变得很大，每次改动一个地方，都要对整个结构进行编译（假如是多个工程），所以我们想到了对它进行重构，剥开耦合。

namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.Before
{
    public class ClientCode
    {
        public decimal CalculateShipping()
        {
            ShippingInfo shippingInfo = new ShippingInfo();
            return shippingInfo.CalculateShippingAmount(State.Alaska);
        }
    }

    public enum State
    {
        Alaska,
        NewYork,
        Florida
    }

    public class ShippingInfo
    {
        public decimal CalculateShippingAmount(State shipToState)
        {
            switch (shipToState)
            {
                case State.Alaska:
                    return GetAlaskaShippingAmount();
                case State.NewYork:
                    return GetNewYorkShippingAmount();
                case State.Florida:
                    return GetFloridaShippingAmount();
                default:
                    return 0m;
            }
        }

        private decimal GetAlaskaShippingAmount()
        {
            return 15m;
        }

        private decimal GetNewYorkShippingAmount()
        {
            return 10m;
        }

        private decimal GetFloridaShippingAmount()
        {
            return 3m;
        }
    }
}

重构后的代码如下所示，抽象出一个IShippingCalculation 接口，然后把ShippingInfo 类里面的GetAlaskaShippingAmount、GetNewYorkShippingAmount、GetFloridaShippingAmount三个方法分别提炼成三个类，然后继承自IShippingCalculation 接口，这样在调用的时候就可以通过IEnumerable<IShippingCalculation> 来解除之前的switch case语句，这和IOC的做法颇为相似。

using System;
using System.Collections.Generic;
using System.Linq;

namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.After_WithIoC
{
    public interface IShippingInfo
    {
        decimal CalculateShippingAmount(State state);
    }

    public class ClientCode
    {
        [Inject]
        public IShippingInfo ShippingInfo { get; set; }

        public decimal CalculateShipping()
        {
            return ShippingInfo.CalculateShippingAmount(State.Alaska);
        }
    }

    public enum State
    {
        Alaska,
        NewYork,
        Florida
    }

    public class ShippingInfo : IShippingInfo
    {
        private IDictionary<State, IShippingCalculation> ShippingCalculations { get; set; }

        public ShippingInfo(IEnumerable<IShippingCalculation> shippingCalculations)
        {
            ShippingCalculations = shippingCalculations.ToDictionary(calc => calc.State);
        }

        public decimal CalculateShippingAmount(State shipToState)
        {
            return ShippingCalculations[shipToState].Calculate();
        }
    }

    public interface IShippingCalculation
    {
        State State { get; }
        decimal Calculate();
    }

    public class AlaskShippingCalculation : IShippingCalculation
    {
        public State State { get { return State.Alaska; } }

        public decimal Calculate()
        {
            return 15m;
        }
    }

    public class NewYorkShippingCalculation : IShippingCalculation
    {
        public State State { get { return State.NewYork; } }

        public decimal Calculate()
        {
            return 10m;
        }
    }

    public class FloridaShippingCalculation : IShippingCalculation
    {
        public State State { get { return State.Florida; } }

        public decimal Calculate()
        {
            return 3m;
        }
    }
}

总结：这种重构在设计模式当中把它单独取了一个名字——策略模式，这样做的好处就是可以隔开耦合，以注入的形式实现功能，这使增加功能变得更加容易和简便，同样也增强了整个系统的稳定性和健壮性。

12. 分解依赖

概念：本文中的“分解依赖” 是指对部分不满足我们要求的类和方法进行依赖分解，通过装饰器来达到我们需要的功能。

正文：正如下面代码所示，如果你要在你的代码中加入单元测试但有一部分代码是你不想测试的，那么你应用使用这个的重构。下面的例子中我们应用静态类来完成某些工作，但问题是在单元测试时我们无法mock静态类，所以我们只能引入静态类的装饰接口来分解对静态类的依赖。从而我们使我们的调用类只需要依赖于装饰接口就能完成这个操作。

namespace LosTechies.DaysOfRefactoring.BreakDependencies.Before
{
    public class AnimalFeedingService
    {
        private bool FoodBowlEmpty { get; set; }

        public void Feed()
        {
            if (FoodBowlEmpty)
                Feeder.ReplenishFood();

            // more code to feed the animal
        }
    }

    public static class Feeder
    {
        public static void ReplenishFood()
        {
            // fill up bowl
        }
    }
}

重构后代码如下，我们添加一个接口和一个实现类，在实现类中调用静态类的方法，所以说具体做什么事情没有改变，改变的只是形式，但这样做的一个好处是增加了了代码的可测试性。在应用了分解依赖模式后，我们就可以在单元测试的时候mock一个IFeederService对象并通过AnimalFeedingService的构造函数传递给它。这样就可以完成我们需要的功能。

namespace LosTechies.DaysOfRefactoring.BreakDependencies.After
{
    public class AnimalFeedingService
    {
        public IFeederService FeederService { get; set; }

        public AnimalFeedingService(IFeederService feederService)
        {
            FeederService = feederService;
        }

        private bool FoodBowlEmpty { get; set; }

        public void Feed()
        {
            if (FoodBowlEmpty)
                FeederService.ReplenishFood();

            // more code to feed the animal
        }
    }

    public interface IFeederService
    {
        void ReplenishFood();
    }

    public class FeederService : IFeederService
    {
        public void ReplenishFood()
        {
            Feeder.ReplenishFood();
        }
    }

    public static class Feeder
    {
        public static void ReplenishFood()
        {
            // fill up bowl
        }
    }
}

总结：这个重构在很多时候和设计模式中的一些思想类似，使用中间的装饰接口来分解两个类之间的依赖，对类进行装饰，然后使它满足我们所需要的功能。

13. 提取方法对象

概念：本文中的“提取方法对象”是指当你发现一个方法中存在过多的局部变量时，你可以通过使用“提取方法对象”重构来引入一些方法，每个方法完成任务的一个步骤，这样可以使得程序变得更具有可读性。

正文：如下代码所示，Order 类中的Calculate方法要完成很多功能，在之前我们用“提取方法”来进行重构，现在我们采取“提取方法对象”来完成重构。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.ExtractMethodObject.Before
{
    public class OrderLineItem
    {
        public decimal Price { get; private set; }
    }

    public class Order
    {
        private IList<OrderLineItem> OrderLineItems { get; set; }
        private IList<decimal> Discounts { get; set; }
        private decimal Tax { get; set; }

        public decimal Calculate()
        {
            decimal subTotal = 0m;

            // Total up line items
            foreach (OrderLineItem lineItem in OrderLineItems)
            {
                subTotal += lineItem.Price;
            }

            // Subtract Discounts
            foreach (decimal discount in Discounts)
                subTotal -= discount;

            // Calculate Tax
            decimal tax = subTotal * Tax;

            // Calculate GrandTotal
            decimal grandTotal = subTotal + tax;

            return grandTotal;
        }
    }
}

正如下代码所示，我们引入了OrderCalculator类，该类实现了所有的计算方法，Order类将自身传递给 OrderCalculator类并调用Calculate方法完成计算过程。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.ExtractMethodObject.After
{
    public class OrderLineItem
    {
        public decimal Price { get; private set; }
    }

    public class Order
    {
        public IEnumerable<OrderLineItem> OrderLineItems { get; private set; }
        public IEnumerable<decimal> Discounts { get; private set; }
        public decimal Tax { get; private set; }

        public decimal Calculate()
        {
            return new OrderCalculator(this).Calculate();
        }
    }

    public class OrderCalculator
    {
        private decimal SubTotal { get; set; }
        private IEnumerable<OrderLineItem> OrderLineItems { get; set; }
        private IEnumerable<decimal> Discounts { get; set; }
        private decimal Tax { get; set; }

        public OrderCalculator(Order order)
        {
            OrderLineItems = order.OrderLineItems;
            Discounts = order.Discounts;
            Tax = order.Tax;
        }

        public decimal Calculate()
        {
            CalculateSubTotal();

            SubtractDiscounts();

            CalculateTax();

            return SubTotal;
        }

        private void CalculateSubTotal()
        {
            // Total up line items
            foreach (OrderLineItem lineItem in OrderLineItems)
                SubTotal += lineItem.Price;
        }

        private void SubtractDiscounts()
        {
            // Subtract Discounts
            foreach (decimal discount in Discounts)
                SubTotal -= discount;
        }

        private void CalculateTax()
        {
            // Calculate Tax
            SubTotal += SubTotal * Tax;
        }
    }
}

总结：本文的重构方法在有的时候还是比较有用，但这样会造成字段的增加，同时也会带来一些维护的不便，它和“提取方法”最大的区别就是一个通过方法返回需要的数据，另一个则是通过字段来存储方法的结果值，所以在很大程度上我们都会选择“提取方法”。

14. 分离职责

概念：本文中的“分离职责”是指当一个类有许多职责时，将部分职责分离到独立的类中，这样也符合面向对象的五大特征之一的单一职责原则，同时也可以使代码的结构更加清晰，维护性更高。

正文：如下代码所示，Video类有两个职责，一个是处理video rental，另一个是计算每个客户的总租金。我们可以将这两个职责分离出来，因为计算每个客户的总租金可以在Customer计算，这也比较符合常理。

using System.Collections.Generic;
using System.Linq;

namespace LosTechies.DaysOfRefactoring.BreakResponsibilities.Before
{
    public class Video
    {
        public void PayFee(decimal fee)
        {
        }

        public void RentVideo(Video video, Customer customer)
        {
            customer.Videos.Add(video);
        }

        public decimal CalculateBalance(Customer customer)
        {
            returncustomer.LateFees.Sum();
        }
    }

    public class Customer
    {
        public IList<decimal> LateFees { get; set; }
        public IList<Video> Videos { get; set; }
    }
}

重构后的代码如下，这样Video 的职责就变得很清晰，同时也使代码维护性更好。

using System.Collections.Generic;
using System.Linq;

namespace LosTechies.DaysOfRefactoring.BreakResponsibilities.After
{
    public class Video
    {
        public void RentVideo(Video video, Customer customer)
        {
            customer.Videos.Add(video);
        }
    }

    public class Customer
    {
        public IList<decimal> LateFees { get; set; }
        public IList<Video> Videos { get; set; }

        public void PayFee(decimal fee)
        {
        }

        public decimal CalculateBalance(Customer customer)
        {
            return customer.LateFees.Sum();
        }
    }
}

总结：这个重构经常会用到，它和之前的“移动方法”有几分相似之处，让方法放在合适的类中，并且简化类的职责，同时这也是面向对象五大原则之一和设计模式中的重要思想。

15. 移除重复内容

概念：本文中的“移除重复内容”是指把一些很多地方都用到的逻辑提炼出来，然后提供给调用者统一调用。

正文：如下代码所示，ArchiveRecord和CloseRecord都会用到Archived = true; 和DateArchived = DateTime.Now; 这两条语句，所以我们就可以对它进行重构。

using System;

namespace LosTechies.DaysOfRefactoring.RemoveDuplication.Before
{
    public class MedicalRecord
    {
        public DateTime DateArchived { get; private set; }
        public bool Archived { get; private set; }

        public void ArchiveRecord()
        {
            Archived = true;
            DateArchived = DateTime.Now;
        }

        public void CloseRecord()
        {
            Archived = true;
            DateArchived = DateTime.Now;
        }
    }
}

重构后的代码如下所示，我们提炼了SwitchToArchived方法来封装公用的操作，然后给ArchiveRecord和CloseRecord统一调用。

using System;

namespace LosTechies.DaysOfRefactoring.RemoveDuplication.After
{
    public class MedicalRecord
    {
        public DateTime DateArchived { get; private set; }
        public bool Archived { get; private set; }

        public void ArchiveRecord()
        {
            SwitchToArchived();
        }

        public void CloseRecord()
        {
            SwitchToArchived();
        }

        private void SwitchToArchived()
        {
            Archived = true;
            DateArchived = DateTime.Now;
        }
    }
}

总结：这个重构很简单，绝大多数程序员都会使用这种重构方法，但有时由于习惯、时间、赶进度等原因而忽略它，所以会使得整个系统杂乱无章，到处都是Ctrl+C和Ctrl+V的痕迹。

16. 封装条件

概念：本文中的“封装条件”是指条件关系比较复杂时，代码的可读性会比较差，所以这时我们应当根据条件表达式是否需要参数将条件表达式提取成可读性更好的属性或者方法，如果条件表达式不需要参数则可以提取成属性，如果条件表达式需要参数则可以提取成方法。

正文：如下代码所示，PerformCoolFunction里面的if条件判断比较复杂，看起来有点杂乱，所以就把它提出来。

using System;

namespace LosTechies.DaysOfRefactoring.EncapsulateConditional.Before
{
    public class RemoteControl
    {
        private string[] Functions { get; set; }
        private string Name { get; set; }
        private int CreatedYear { get; set; }

        public string PerformCoolFunction(string buttonPressed)
        {
            // Determine if we are controlling some extra function
            // that requires special conditions
            if (Functions.Length > 1 && Name == "RCA" && CreatedYear > DateTime.Now.Year - 2)
                return "doSomething";
        }
    }
}

如下代码所示，我们把条件表达式封装成HasExtraFunctions属性，这样先前的条件判断就成了if (HasExtraFunctions) ，所以这样就在很大程度上提高了可读性。

using System;

namespace LosTechies.DaysOfRefactoring.EncapsulateConditional.After
{
    public class RemoteControl
    {
        private string[] Functions { get; set; }
        private string Name { get; set; }
        private int CreatedYear { get; set; }

        private bool HasExtraFunctions
        {
            get { return Functions.Length > 1 && Name == "RCA" && CreatedYear > DateTime.Now.Year - 2; }
        }

        public string PerformCoolFunction(string buttonPressed)
        {
            // Determine if we are controlling some extra function
            // that requires special conditions
            if (HasExtraFunctions)
                return "doSomething";
        }
    }
}

总结：这个重构在很大程度上能改善代码的可读性，尤其是在一个逻辑很复杂的应用中，把这些条件判断封装成一个有意义的名字，这样很复杂的逻辑也会立刻变得简单起来。

17. 提取父类

概念：本文中的“提取父类”是指类中有一些字段或方法，你想把它们提取到父类中以便同一继承层次的其它类也可以访问他们，这个和之前的很多重构有异曲同工之处。

正文：Dog 类中的EatFood和Groom有可能被其他类用到，因为他们都是动物的一些公有性质，所以这个时候我们就会考虑对它进行提炼。

namespace LosTechies.DaysOfRefactoring.ExtractSuperclass.Before
{    
    public class Dog    
    {        
        public void EatFood()        
        {            
            // eat some food        
        }
        
        public void Groom() 
        { 
        // perform grooming 
        } 
    } 
}

代码如下所示，提取了Animal 方法来封装公用的EatFood和Groom类，从而使其他继承了Animal 类的子类都可以使用这两个方法了。

namespace LosTechies.DaysOfRefactoring.ExtractSuperclass.After
{
    public class Animal
    {
        public void EatFood()
        {
            // eat some food
        }

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

    public class Dog : Animal
    {
    }
}

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

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

概念：本文中的“使用条件判断代替异常”是指把没有必要使用异常做判断的条件尽量改为条件判断。

正文：如下代码所示，在日常的编码中我们经常需要用到异常来控制程序流，Start方法里面用try catch 做条件判断，我们知道这里没有必要使用这种方式，因为你不需要做类型不可控的类型转换，也不需要处理异常行为，所以我们应该对它进行重构。

namespace LosTechies.DaysOfRefactoring.ReplaceException.Before
{
    public class Microwave
    {
        private IMicrowaveMotor Motor { get; set; }

        public bool Start(object food)
        {
            bool foodCooked = false;
            try
            {
                Motor.Cook(food);
                foodCooked = true;
            }
            catch (InUseException)
            {
                foodcooked = false;
            }

            return foodCooked;
        }
    }
}

重构后的代码如下所示，try catch 做条件判断的语句改成了if return 的方式，这样在很多程度上统一了代码的书写，同时也提高了性能。

namespace LosTechies.DaysOfRefactoring.ReplaceException.After
{
    public class Microwave
    {
        private IMicrowaveMotor Motor { get; set; }

        public bool Start(object food)
        {
            if (Motor.IsInUse)
                return false;

            Motor.Cook(food);

            return true;
        }
    }
}

总结： 这个重构在项目代码中也经常用到，因为对于一部分程序员，是很难把握什么时候用try catch ，什么地方该用try catch 。记得之前大家还专门讨论过这些，比如如何用好以及在大中型项目中应该把它放在哪一个组件中等。

19. 提取工厂类

概念：本文中的“提取工厂类”是指如果要创建的对象很多，则代码会变的很复杂。一种很好的方法就是提取工厂类。

正文：一般来说我们需要在代码中设置一些对象，以便获得它们的状态，从而使用对象，所谓的设置通常来说就是创建对象的实例并调用对象的方法。有时如果要创建的对象很多，则代码会变的很复杂。这便是工厂模式发挥作用的情形。工厂模式的复杂应用是使用抽象工厂创建对象集，但我们在这里只是使用基本的工厂类创建对象的一个简单应用。

如下代码所示，New方法包含创建类的整个逻辑，如果现在要创建的类比较多而且逻辑比较复杂的话（如根据不同条件创建对象，什么时候创建对象），我们的New方法逻辑会变得很大，同时代码也变得很难维护。所以我们就会采用提取工厂类的方式进行提炼。

namespace LosTechies.DaysOfRefactoring.ExtractServiceClass.Before
{
    public class PoliceCarController
    {
        public PoliceCar New(int mileage, bool serviceRequired)
        {
            PoliceCar policeCar = new PoliceCar();
            policeCar.ServiceRequired = serviceRequired;
            policeCar.Mileage = mileage;

            return policeCar;
        }
    }
}

那么重构后的代码如下，New方法变得很简单了，指需要调用实现接IPoliceCarFactory 接口的PoliceCarFactory 类就可以返回对象，这样就隔开了创建对象的逻辑，如果需求现在变为根据不同的条件创建不同的对象，什么时候创建对象等都变成了比较简单的事情，在后期可以把对象都配置在XML里面，使用反射的方式实现IOC注入创建。

namespace LosTechies.DaysOfRefactoring.ExtractServiceClass.After
{
    public interface IPoliceCarFactory
    {
        PoliceCar Create(int mileage, bool serviceRequired);
    }

    public class PoliceCarFactory : IPoliceCarFactory
    {
        public PoliceCar Create(int mileage, bool serviceRequired)
        {
            PoliceCar policeCar = new PoliceCar();
            policeCar.ReadForService = serviceRequired;
            policeCar.Mileage = mileage;
            return policeCar;
        }
    }

    public class PoliceCarController
    {
        public IPoliceCarFactory PoliceCarFactory { get; set; }

        public PoliceCarController(IPoliceCarFactory policeCarFactory)
        {
            PoliceCarFactory = policeCarFactory;
        }

        public PoliceCar New(int mileage, bool serviceRequired)
        {
            return PoliceCarFactory.Create(mileage, serviceRequired);
        }
    }
}

总结：这个重构经常会在项目中使用，如果要创建的对象是一个，你可以采用简单工厂，但是这种方式还是会存在很多依赖，维护起来也比较不方便。所以推荐使用工厂方法模式，把实例化延迟到子类。如果你要创建一系列的对象，那么就推荐你使用抽象工厂模式，但是要注意不要过度设计，只要能满足不断变化的需求和给以后的维护和重构带来方便即可。

20. 提取子类

概念：本文中的”提取子类”是指把基类中的一些不是所有子类都需要访问的方法调整到子类中。

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

所以我们将NonRegistration和Notes提到单独的NonRegistration类中。

using System;

namespace LosTechies.DaysOfRefactoring.SampleCode.ExtractSubclass.Before
{
    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; }
    }
}

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

using System;

namespace LosTechies.DaysOfRefactoring.SampleCode.ExtractSubclass.After
{
    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; }
    }
}

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

21. 合并继承

概念：本文中的”合并继承”是指如果子类的属性和方法也适合于基类，那么就可以移除子类，从而减少依赖关系。

正文：上一篇我们讲到“提取子类”重构是指当基类中的一个责任不被所有的子类所需要时，将这些责任提取到合适的子类中。而我们今天所要讲的的“合并继承”重构一般用在当我们觉得不需要子类的时候。

如下代码所示，StudentWebSite子类除了有一个属性用来说明网站是否是活动的外没有别的责任，在这种情形下我们意识到IsActive属性可以应用到所有的网站，所以我们可以将IsActive属性上移到基类中，并去掉StudentWebSite类。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.SampleCode.CollapseHierarchy.Before
{
    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; }
    }
}

重构后的代码如下：

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.SampleCode.CollapseHierarchy.After
{
    public class Website
    {
        public string Title { get; set; }
        public string Description { get; set; }
        public IEnumerable<Webpage> Pages { get; set; }
        public bool IsActive { get; set; }
    }
}

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

22. 分解方法

概念：本文中的”分解方法”是指把我们所做的这个功能不停的分解方法，直到将一个大方法分解为名字有意义且可读性更好的若干个小方法。

正文：如下代码所示，因为现实中AcceptPayment方法不会做这么多的事情。，所以我们通过几次分解将 AcceptPayment拆分成若干个名字有意义且可读性更好的小方法。

using System.Collections.Generic;
using System.Linq;

namespace LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.Before
{
    public class CashRegister
    {
        public CashRegister()
        {
            Tax = 0.06m;
        }

        private decimal Tax { get; set; }

        public void AcceptPayment(Customer customer, IEnumerable<Product> products, decimal payment)
        {
            decimal subTotal = 0m;
            foreach (Product product in products)
            {
                subTotal += product.Price;
            }

            foreach (Product product in products)
            {
                subTotal -= product.AvailableDiscounts;
            }

            decimal grandTotal = subTotal * Tax;

            customer.DeductFromAccountBalance(grandTotal);
        }
    }

    public class Customer
    {
        public void DeductFromAccountBalance(decimal amount)
        {
            // deduct from balance
        }
    }

    public class Product
    {
        public decimal Price { get; set; }
        public decimal AvailableDiscounts { get; set; }
    }
}

重构后的代码如下，我们把AcceptPayment的内部逻辑拆分成了CalculateSubtotal、SubtractDiscounts、AddTax、SubtractFromCustomerBalance四个功能明确且可读性更好的小方法。

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After
{
    public class CashRegister
    {
        public CashRegister()
        {
            Tax = 0.06m;
        }

        private decimal Tax { get; set; }
        private IEnumerable<Product> Products { get; set; }

        public void AcceptPayment(Customer customer, IEnumerable<Product> products, decimal payment)
        {
            decimal subTotal = CalculateSubtotal();

            subTotal = SubtractDiscounts(subTotal);

            decimal grandTotal = AddTax(subTotal);

            SubtractFromCustomerBalance(customer, grandTotal);
        }

        private void SubtractFromCustomerBalance(Customer customer, decimal grandTotal)
        {
            customer.DeductFromAccountBalance(grandTotal);
        }

        private decimal AddTax(decimal subTotal)
        {
            return subTotal * Tax;
        }

        private decimal SubtractDiscounts(decimal subTotal)
        {
            foreach (Product product in Products)
            {
                subTotal -= product.AvailableDiscounts;
            }
            return subTotal;
        }

        private decimal CalculateSubtotal()
        {
            decimal subTotal = 0m;
            foreach (Product product in Products)
            {
                subTotal += product.Price;
            }
            return subTotal;
        }
    }

    public class Customer
    {
        public void DeductFromAccountBalance(decimal amount)
        {
            // deduct from balance
        }
    }

    public class Product
    {
        public decimal Price { get; set; }
        public decimal AvailableDiscounts { get; set; }
    }
}

总结：其实这个重构和我们前面讲的“提取方法”和“提取方法对象”如出一辙，尤其是“提取方法”，所以大家只要知道用这种思想重构就行。

23. 引入参数对象

概念：本文中的“引入参数对象”是指当一个方法的参数过多或者过为复杂时，可以考虑把这些参数封装成一个单独的类。

正文：如果一个方法所需要的参数大于5个，理解该方法的签名就变得比较困难，因为这样感觉参数很长、样式不好并且没有分类，所以我们有必要把参数进行封装。

namespace LosTechies.DaysOfRefactoring.SampleCode.ParameterObject.Before
{
    public class Registration
    {
        public void Create(decimal amount, Student student, IEnumerable<Course> courses, decimal credits)
        {
            // do work
        }
    }
}

通常这种情形下创建一个用户传递参数的类是很有帮助的，这会使得代码更容易明白也更灵活，因为当你需要增加参数时，只需要给参数类添加一个属性即可。请注意只有当你发现方法的参数比较多时才应该应用该重构，如果方法的参数比较少，就没有必要应用此重构，因为该重构会增加系统中类的数量，同时也会加大维护负担。所以要看参数情况而定。
重构后的代码如下：

using System.Collections.Generic;

namespace LosTechies.DaysOfRefactoring.SampleCode.ParameterObject.After
{
    public class RegistrationContext
    {
        public decimal Amount { get; set; }
        public Student Student { get; set; }
        public IEnumerable<Course> Courses { get; set; }
        public decimal Credits { get; set; }
    }

    public class Registration
    {
        public void Create(RegistrationContext registrationContext)
        {
            // do work
        }
    }
}

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

24. 分解复杂判断

概念：本文中的”分解复杂判断”是指把原来复杂的条件判断等语句用尽快返回等方式简化代码。

正文：简单的来说，当你的代码中有很深的嵌套条件时，花括号就会在代码中形成一个长长的箭头。我们经常在不同的代码中看到这种情况，并且这种情况也会扰乱代码的可读性。

如下代码所示，HasAccess方法里面包含一些嵌套条件，如果再加一些条件或者增加复杂度，那么代码就很可能出现几个问题：1，可读性差。 2，很容易出现异常。 3，性能较差。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace LosTechies.DaysOfRefactoring.SampleCode.ArrowheadAntipattern.Before
{
    public class Security
    {
        public ISecurityChecker SecurityChecker { get; set; }

        public Security(ISecurityChecker securityChecker)
        {
            SecurityChecker = securityChecker;
        }

        public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)
        {
            bool hasPermission = false;

            if (user != null)
            {
                if (permission != null)
                {
                    if (exemptions.Count() == 0)
                    {
                        if (SecurityChecker.CheckPermission(user, permission) || exemptions.Contains(permission))
                        {
                            hasPermission = true;
                        }
                    }
                }
            }

            return hasPermission;
        }
    }
}

那么重构上面的代码也很简单，如果有可能的话，尽量将条件从方法中移除，我们让代码在做处理任务之前先检查条件，如果条件不满足就尽快返回，不继续执行。下面是重构后的代码：

using System.Collections.Generic;
using System.Linq;

namespace LosTechies.DaysOfRefactoring.SampleCode.ArrowheadAntipattern.After
{
    public class Security
    {
        public ISecurityChecker SecurityChecker { get; set; }

        public Security(ISecurityChecker securityChecker)
        {
            SecurityChecker = securityChecker;
        }

        public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)
        {
            if (user == null || permission == null)
                return false;

            if (exemptions.Contains(permission))
                return true;

            return SecurityChecker.CheckPermission(user, permission);
        }
    }
}

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

25. 引入契约式设计

概念：本文中的”引入契约式设计”是指我们应该对应该对输入和输出进行验证，以确保系统不会出现我们所想象不到的异常和得不到我们想要的结果。

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

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace LosTechies.DaysOfRefactoring.SampleCode.Day25_DesignByContract
{
    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。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Contracts;

namespace LosTechies.DaysOfRefactoring.SampleCode.DesignByContract.After
{
    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的设计，就不难发现了。这个重构建议大家经常使用，这会增强整个系统的稳定性和健壮性。

26. 避免双重否定

概念：本文中的“避免双重否定”是指把代码中的双重否定语句修改成简单的肯定语句，这样即让代码可读，同时也给维护带来了方便。

正文：避免双重否定重构本身非常容易实现，但我们却在太多的代码中见过因为双重否定降低了代码的可读性以致于非常让人容易误解真正意图。存在双重否定的代码具有非常大的危害性，因为这种类型的代码容易引起错误的假设，错误的假设又会导致书写出错误的维护代码，最终会导致bug产生。具体可以看下面的代码：

using  System.Collections.Generic;
using  LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace  LosTechies.DaysOfRefactoring.SampleCode.DoubleNegative.Before
{
    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; }
        }
    }
}

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

using System.Collections.Generic;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.DoubleNegative.After
{
    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; }
        }
    }
}

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

27. 去除上帝类

概念：本文中的“去除上帝类”是指把一个看似功能很强且很难维护的类，按照职责把自己的属性或方法分派到各自的类中或分解成功能明确的类，从而去掉上帝类。

正文：我们经常可以在一些原来的代码中见到一些类明确违反了SRP原则（单一原则），这些类通常以“Utils”或“Manager”后缀结尾，但有时这些类也没有这些特征，它仅仅是多个类多个方法的组合。另一个关于上帝类的特征是通常这些类中的方法被用注释分隔为不同的分组。那么久而久之，这些类被转换为那些没有人愿意进行归并到合适类的方法的聚集地，对这些类进行重构是将类中的代码按照职责分派到各自的类中，这样就解除了上帝类，也减轻了维护的负担。

using System.Collections.Generic;
using LosTechies.DaysOfRefactoring.EncapsulateCollection.After;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;
using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer;

namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveGodClasses.Before
{
    public class CustomerService
    {
        public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)
        {
            // do work
        }

        public bool CustomerIsValid(Customer customer, Order order)
        {
            // do work
        }

        public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)
        {
            // do work
        }

        public void Register(Customer customer)
        {
            // do work
        }

        public void ForgotPassword(Customer customer)
        {
            // do work
        }
    }
}

我们看到要重构上面的代码是很简单的，只要将相关的方法按职责分派到对应的类中即可，带来的好处就是这会降低代码的颗粒度并减少未来维护代码的成本。下面是重构后的代码，它将上面

的代码按照职责分为了两个不同的类。

using System.Collections.Generic;
using LosTechies.DaysOfRefactoring.EncapsulateCollection.After;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;
using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer;

namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveGodClasses.After
{
    public class CustomerOrderService
    {
        public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)
        {
            // do work
        }

        public bool CustomerIsValid(Customer customer, Order order)
        {
            // do work
        }

        public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)
        {
            // do work
        }
    }

    public class CustomerRegistrationService
    {

        public void Register(Customer customer)
        {
            // do work
        }

        public void ForgotPassword(Customer customer)
        {
            // do work
        }
    }
}

总结： “去除上帝类”是我们经常容易造成的，第一是因为简便，看到有一个现成的类，大家都会喜欢把代码往里面写，最后导致越写越大，并且声明功能都有，这样即降低了可读性，也造成了维护的负担。

28. 为布尔方法命名

概念：本文中的“为布尔方法命名”是指如果一个方法带有大量的bool 参数时，可以根据bool 参数的数量，提取出若干个独立的方法来简化参数。

正文：我们现在要说的重构并不是普通字面意义上的重构，它有很多值得讨论的地方。当一个方法带有大量的bool 参数时，会导致方法很容易被误解并产生非预期的行为，

根据布尔型参数的数量，我们可以决定提取出若干个独立的方法来。具体代码如下：

using LosTechies.DaysOfRefactoring.BreakResponsibilities.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.RenameBooleanMethod.Before
{
    public class BankAccount
    {
        public void CreateAccount(Customer customer, bool withChecking, bool withSavings, bool withStocks)
        {
            // do work
        }
    }
}

我们可以将上面的bool参数以独立方法的形式暴露给调用端以提高代码的可读性，同时我们还需要将原来的方法改为private以限制其可访问性。显然我们关于要

提取的独立方法会有一个很大的排列组合，这是一大缺点，所以我们可以考虑引入”参数对象“重构。

using LosTechies.DaysOfRefactoring.BreakResponsibilities.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.RenameBooleanMethod.After
{
    public class BankAccount
    {
        public void CreateAccountWithChecking(Customer customer)
        {
            CreateAccount(customer, true, false);
        }

        public void CreateAccountWithCheckingAndSavings(Customer customer)
        {
            CreateAccount(customer, true, true);
        }

        private void CreateAccount(Customer customer, bool withChecking, bool withSavings)
        {
            // do work
        }
    }
}

总结： “为布尔方法命名”这个重构在很多时候都不常用，如果用户的参数可枚举，我们一般会枚举它的值，不过使用这种重构也有好处，就是分解开来以后，方法多了，参数少了，代码维护起来方便了一些。

29. 去除中间人对象

概念：本文中的“去除中间人对象”是指把在中间关联而不起任何其他作用的类移除，让有关系的两个类直接进行交互。

正文：有些时候在我们的代码会存在一些“幽灵类”，设计模式大师Fowler称它们为“中间人”类，“中间人”类除了调用别的对象之外不做任何事情，所以“中间人”类没有存在的必要，我们可以将它们从代码中删除，从而让交互的两个类直接关联。

如下代码所示，Consumer 类要得到AccountDataProvider 的数据，但中间介入了没起任何作用的 AccountManager 类来关联，所以我们应当移除。

using LosTechies.DaysOfRefactoring.PullUpField.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveMiddleMan.Before
{
    public class Consumer
    {
        public AccountManager AccountManager { get; set; }

        public Consumer(AccountManager accountManager)
        {
            AccountManager = accountManager;
        }

        public void Get(int id)
        {
            Account account = AccountManager.GetAccount(id);
        }
    }

    public class AccountManager
    {
        public AccountDataProvider DataProvider { get; set; }

        public AccountManager(AccountDataProvider dataProvider)
        {
            DataProvider = dataProvider;
        }

        public Account GetAccount(int id)
        {
            return DataProvider.GetAccount(id);
        }
    }

    public class AccountDataProvider
    {
        public Account GetAccount(int id)
        {
            // get account
        }
    }
}

重构后的代码如下所示，Consumer 和AccountDataProvider 直接进行关联，这样代码就简单了。

using LosTechies.DaysOfRefactoring.PullUpField.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveMiddleMan.After
{
    public class Consumer
    {
        public AccountDataProvider AccountDataProvider { get; set; }

        public Consumer(AccountDataProvider dataProvider)
        {
            AccountDataProvider = dataProvider;
        }

        public void Get(int id)
        {
            Account account = AccountDataProvider.GetAccount(id);
        }
    }

    public class AccountDataProvider
    {
        public Account GetAccount(int id)
        {
            // get account
        }
    }
}

总结： “去除中间人对象”很多时候都会很有作用，尤其是在误用设计模式的代码中最容易见到，设计模式中的适配器模式和代理模式等都用中间的类是两者进行关联，这是比较合理的，因为中间类做了很多事情，而对于没有任何作用的中间类应该移除。

30. 尽快返回

概念： 本文中的“尽快返回”是指把原来复杂的条件判断等语句用尽快返回的方式简化代码。

正文：如首先声明的是前面讲的“分解复杂判断”，简单的来说，当你的代码中有很深的嵌套条件时，花括号就会在代码中形成一个长长的箭头。我们经常在不同的代码中看到这种情况，并且这种情况也会扰乱代码的可读性。下代码所示，HasAccess方法里面包含一些嵌套条件，如果再加一些条件或者增加复杂度，那么代码就很可能出现几个问题：1，可读性差 2，很容易出现异常 3，性能较差

using System.Collections.Generic;
using System.Linq;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;
using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer;

namespace LosTechies.DaysOfRefactoring.SampleCode.ReturnASAP.Before
{
    public class Order
    {
        public Customer Customer { get; private set; }

        public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts)
        {
            Customer = customer;
            decimal orderTotal = 0m;

            if (products.Count() > 0)
            {
                orderTotal = products.Sum(p => p.Price);
                if (discounts > 0)
                {
                    orderTotal -= discounts;
                }
            }

            return orderTotal;
        }
    }
}

那么重构上面的代码也很简单，如果有可能的话，尽量将条件判断从方法中移除，我们让代码在做处理任务之前先检查条件，如果条件不满足就尽快返回，不继续执行。

下面是重构后的代码：

using System.Collections.Generic;
using System.Linq;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;
using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer;

namespace LosTechies.DaysOfRefactoring.SampleCode.ReturnASAP.After
{
    public class Order
    {
        public Customer Customer { get; private set; }

        public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts)
        {
            if (products.Count() == 0)
                return 0;

            Customer = customer;
            decimal orderTotal = products.Sum(p => p.Price);

            if (discounts == 0)
                return orderTotal;

            orderTotal -= discounts;

            return orderTotal;
        }
    }
}

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

31. 使用多态代替条件判断

概念：本文中的“使用多态代替条件判断”是指如果你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。

正文：本文展示了面向对象编程的基础之一“多态性”，有时你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。

如下代码所示，OrderProcessor 类的ProcessOrder方法根据Customer 的类型分别执行一些操作，正如上面所讲的那样，我们最好将OrderProcessor 类中这些算法（数据或操作）封装在特定的Customer 子类中。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.ReplaceWithPolymorphism.Before
{
    public abstract class Customer
    {
    }

    public class Employee : Customer
    {
    }

    public class NonEmployee : Customer
    {
    }

    public class OrderProcessor
    {
        public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
        {
            // do some processing of order
            decimal orderTotal = products.Sum(p => p.Price);

            Type customerType = customer.GetType();
            if (customerType == typeof(Employee))
            {
                orderTotal -= orderTotal * 0.15m;
            }
            else if (customerType == typeof(NonEmployee))
            {
                orderTotal -= orderTotal * 0.05m;
            }

            return orderTotal;
        }
    }
}

重构后的代码如下，每个Customer 子类都封装自己的算法，然后OrderProcessor 类的ProcessOrder方法的逻辑也变得简单并且清晰了。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.ReplaceWithPolymorphism.After
{
    public abstract class Customer
    {
        public abstract decimal DiscountPercentage { get; }
    }

    public class Employee : Customer
    {
        public override decimal DiscountPercentage
        {
            get { return 0.15m; }
        }
    }

    public class NonEmployee : Customer
    {
        public override decimal DiscountPercentage
        {
            get { return 0.05m; }
        }
    }

    public class OrderProcessor
    {
        public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
        {
            // do some processing of order
            decimal orderTotal = products.Sum(p => p.Price);

            orderTotal -= orderTotal * customer.DiscountPercentage;

            return orderTotal;
        }
    }
}

总结： “使用多态代替条件判断”这个重构在很多时候会出现设计模式中（常见的工厂家族、策略模式等都可以看到它的影子），因为运用它可以省去很多的条件判断，同时也能简化代码、规范类和对象之间的职责。

代码及PDF下载

代码下载地址：http://github.com/schambers/days-of-refactoring

中文版PDF下载地址：猛击下载

你可能感兴趣的:(学习笔记)

【一起学Rust | 设计模式】习惯语法——使用借用类型作为参数、格式化拼接字符串、构造函数广龙宇一起学Rust #Rust设计模式 rust 设计模式开发语言
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录前言一、使用借用类型作为参数二、格式化拼接字符串三、使用构造函数总结前言Rust不是传统的面向对象编程语言，它的所有特性，使其独一无二。因此，学习特定于Rust的设计模式是必要的。本系列文章为作者学习《Rust设计模式》的学习笔记以及自己的见解。因此，本系列文章的结构也与此书的结构相同（后续可能会调成结构），基本上分为三个部分
四章-32-点要素的聚合彩云飘过
本文基于腾讯课堂老胡的课《跟我学Openlayers--基础实例详解》做的学习笔记，使用的openlayers5.3.xapi。源码见1032.html，对应的官网示例https://openlayers.org/en/latest/examples/cluster.htmlhttps://openlayers.org/en/latest/examples/earthquake-clusters.
语文主题教学学习笔记之87 东哥杂谈
“语文主题教学”学习笔记之八十七（0125）今天继续学习小学语文主题教学的实践样态。板块三：教学中体现“书艺”味道。作为四大名著之一的《水浒传》，堪称我国文学宝库之经典。对从《水浒传》中摘选的单元，教师就要了解其原生态，即评书体特点。这也要求教师要了解一些常用的评书行话术语，然后在教学时适时地加入一些，让学生体味其文本中原有的特色。学生也要尽可能地通过朗读的方式，而不单是分析讲解的方式进行学习。细
《转介绍方法论》学习笔记小可乐的妈妈
一、高效转介绍的流程：价值观---执行----方案一）转介绍发生的背景：1、对象：谁向谁转介绍？全员营销，人人参与。①员工的激励政策、客户的转介绍诱因制作客户画像：a信任；支付能力；意愿度；便利度（根据家长具备四个特征的个数分为四类）B性格分类C职业分类D年龄性别②执行：套路，策略，方法，流程2、诱因：为什么要转介绍？认同信任；多方共赢；传递美好；零风险承诺打动人心，超越期待。选择做教育，就是选择
JAVA学习笔记之23种设计模式学习 victorfreedom Java技术设计模式 android java 常用设计模式
博主最近买了《设计模式》这本书来学习，无奈这本书是以C++语言为基础进行说明，整个学习流程下来效率不是很高，虽然有的设计模式通俗易懂，但感觉还是没有充分的掌握了所有的设计模式。于是博主百度了一番，发现有大神写过了这方面的问题，于是博主迅速拿来学习。一、设计模式的分类总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器
新能源汽车 BMS 学习笔记篇—BMS 基本定义及分类 WPG大大通其他笔记汽车 BMS 经验分享新能源电池
一、BMS定义1、概念：BMS（BatteryManagementSystem）即电池管理系统，其管理对象是二次电池（充电电池或蓄电池），其主要目的是电池的利用率，防止电池出现过度充电和过度放电，可应用于电动汽车、电瓶车、机器人、无人机等图片来源：腾讯网https://new.qq.com《标准普尔警告，电动汽车电池生产面临供应链和地缘政治风险》2、四大功能①感知和测量：检测电池的电压、电流、温度
吴恩达深度学习笔记(30)-正则化的解释极客Array
正则化（Regularization）深度学习可能存在过拟合问题——高方差，有两个解决方法，一个是正则化，另一个是准备更多的数据，这是非常可靠的方法，但你可能无法时时刻刻准备足够多的训练数据或者获取更多数据的成本很高，但正则化通常有助于避免过拟合或减少你的网络误差。如果你怀疑神经网络过度拟合了数据，即存在高方差问题，那么最先想到的方法可能是正则化，另一个解决高方差的方法就是准备更多数据，这也是非常
个人学习笔记7-6：动手学深度学习pytorch版-李沐浪子L 深度学习深度学习笔记计算机视觉 python 人工智能神经网络 pytorch
#人工智能##深度学习##语义分割##计算机视觉##神经网络#计算机视觉13.11全卷积网络全卷积网络（fullyconvolutionalnetwork，FCN）采用卷积神经网络实现了从图像像素到像素类别的变换。引入l转置卷积（transposedconvolution）实现的，输出的类别预测与输入图像在像素级别上具有一一对应关系：通道维的输出即该位置对应像素的类别预测。13.11.1构造模型下
golang学习笔记--MPG模型 xxzed golang #学习笔记学习笔记 golang
MPG模式：M（Machine）：操作系统的主线程P（Processor）：协程执行需要的资源（上下文context），可以看作一个局部的调度器，使go代码在一个线程上跑，他是实现从N：1到N：M映射的关键G（Goroutine）：协程，有自己的栈。包含指令指针（instructionpointer）和其它信息（正在等待的channel等等），用于调度。一个P下面可以有多个G1、当前程序有三个M,
碎片化学习笔记分享剑客写作
现在生活节奏很快，学习力成为了我们拥有的最大财富。碎片化学习是最好的。首先，不要太过自信，学会虚心学习，是我们面对现实的好方法，才能够常保新鲜。平时我们要拥有什么工具呢？1.思维导图2.写在印象笔记里3.听书，消燥耳机4.教学输出5.录音笔里面最好的方式就是教学输出法，记忆里最好。当输出时我们集中精力记忆里最好。有人认为缩短睡眠时间来学习，其实最好的方式是保持最好的睡眠，记忆力会更好。剥夺睡眠，会
《随园诗话》学习笔记三百零六飞鸿雪舞
卷五凡诗之传者，都在灵性五、五斗米与诗【原文】丁丑，余觅一抄书人，或荐黄生，名之纪，号星岩者，人甚朴野。偶过其案头，得句云；“破庵僧卖临街瓦，独井人争向晚泉。”余大奇之，即饷米五斗。自此欣然大用力于诗。五言句云：“云开日脚直，雨落水纹圆。竹锐穿泥壁，蝇酣落酒尊。钓久知鱼性，樵多识树名。笔残芦并用，墨尽指同磨。＂七言云：＂小窗近水寒偏觉，古木遮天曙不知。旧生萍处泥犹绿，新落花时水亦香。旧甓恐闲都贮水
D15 论语学习笔记许小兔Angelina
悟：上级对下级的宽容：凡事成定局，就不你说了；已接近完结的事，也没必要匡正和挽回了；既然是过去的事，也没必要追究得失和责任了。对待孩子教育也是，不用“问责制”，这样容易让孩子因为害怕担责而说谎。应当循循善诱，避免再犯错才是最重要的。3.16：【原文】子曰：“射不主皮，为力不同科，古之道也。”【译文】孔子说：“射箭比赛不以射透为主，而主要看是否射得准确，因为人的力量不同，自古如此。”3.17：【原文
网络工程师学习笔记（一）专业白嫖怪网络工程师学习笔记学习笔记网络
为了备战下半年的软考——网络工程师，利用每天的下班的闲暇时间看书听课，然后自己手敲整理的系列资料。希望能够对你们有所帮助第一章__计算机网络概述计算机网络的定义：将分散的具有独立运算功能的计算机系统，通过通信线路和通信设备进行连接起来的实现资源的共享。ARPAnet网络的特征：资源共享、分散控制、分组交换1946年第一台通用计算机—埃尼亚克能够相互连通进行数据交换。1960年提出巨型网络，出现了对
K8S学习笔记02——K8S组件沉淅尘 #Docker #K8S kubernetes
Kubernetes组件一、控制平面组件（ControlPlaneComponents）(1)kube-apiserver(2)etcd(3)kube-scheduler(4)kube-controller-manager(5)cloud-controller-manager二、Node组件1.kubelet2.kube-proxy3.容器运行时（ContainerRuntime）三、插件（Add
「Python」2020.04.08学习笔记 | 第六章文件（a+）模式+把随机手机号写入文件小练习 Yetta的书影屋
学习测试开发的Day97，真棒！学习时间为40M第九次全天课(下午视频二20M-50M）>>>fp.seek(0)0>>>fp.read()'你好11你好12你好13你好14你好15\n你好16\n你好17\n你好18\n'>>>fp.seek(0,0)0>>>fp.write("*********************************\n")34>>>fp.seek(0,0)0>>>f
《金文成〈中庸〉学习笔记401。2020-2-24》金吾生
《金文成〈中庸〉学习笔记401。2020-2-24》今天是庚子年戊寅月丁酉日，二月初二，2020年2月24日星期一。二月二龙抬头。第二十二章【唯天下至诚，为能尽其性；能尽其性，则能尽人之性；能尽人之性，则能尽物之性；能尽物之性，则能赞天地之化育；能赞天地之化育，则可以与天地参矣。】上一节，船山讲解说，性作为天用之本体，于圣人和匹夫匹妇而言并无二致，区别来自于诚。诚的区别来自于纯粹与掺杂。掺杂什么呢
CDGA学习笔记三-《数据安全》 zy_chris 网络安全
七、数据安全7.1引言数据安全包括安全策略和过程的规划、建立与执行，为数据和信息资产提供正确的身份验证、授权、访问和审计。要求来自以下方面：（1）利益相关方（2）政府法规（3）特定业务关注点（4）合法访问需求（5）合同义务7.1.1业务驱动因素1、降低风险信息安全首先对组织数据进行分级分类，对组织数据进行分类分级的整个流程：1）识别敏感数据资产并分类分级2）在企业中查找敏感数据3）确定保护每项资产
vue学习笔记——关于对Vue3 ref(), toRef(), toRefs(), unref(), isRef(), reactive()方法的理解。 chen_sir_sh vue学习笔记 javascript 前端 vue
VUE3出现了很多新的API，下面是自己的一些理解进行的总结。欢迎大家一起交流补充。ref()使用ref创建一个数据类型，ref有value这个属性constname1={age:"14",name:"bob1"};constname2=ref({name:"bob2"});//使用ref创建一个数据类型相对于reactive，ref有value属性name2.value="bob3"consol
遇到僵尸进程，怎么处理---学习笔记 summer@彤妈性能优化 linux
僵尸进程解释当iowait升高时，进程很可能因为得不到硬件的响应，而长时间处于不可中断状态。从ps或者top命令的输出中，你可以发现它们都处于D状态，也就是不可中断状态（UninterruptibleSleep）。既然说到了进程的状态，进程有哪些状态你还记得吗？我们先来回顾一下。top和ps是最常用的查看进程状态的工具，我们就从top的输出开始。下面是一个top命令输出的示例，S列（也就是Stat
C++学习笔记----6、内存管理（五）---- 智能指针（3）王俊山IT c++学习笔记开发语言
2、shared_ptr有时候吧，有些对象或者一部分代码需要同一个指针的拷贝。那么unique_ptr不能被拷贝，因此就不能用于些场景。这样的话，std::shared_ptr就是一个支持能够被拷贝的拥有共享属主的智能指针。但是，如果有指向同一个资源的多个shared_ptr实例，那么怎么知道什么时候去释放资源呢？这可以通过对于引用记数来解决，这个我们以后再聊。首先，让我们看一下怎么构造与使用sh
【学习笔记】武志红心理学—潜意识决定命运万万千千
冰山一角什么构成了我们的命运？命运是由我们的显意识和潜意识来决定的。我们可以用一张图做一个比喻。看过“冰山一角”图片的都知道，潜意识就是水面以下的部分，显意识是水面以上的部分，从体积来看，潜意识占了大部分，而显意识只是冰山一角，纵向来看，庞大的潜意识支撑着冰山一角的显意识，才得以让冰山漂浮在水面。延伸到我们的人生，我们对自己显意识层面的想法很容易感知到，所以我们会说这是“我”自己做的选择。而潜意识
Prism 教程 yang_B621 Prism IOC
http://t.csdnimg.cn/VXSSvhttps://blog.csdn.net/u010476739/article/details/119341731Prism-随笔分类-Hello——寻梦者！-博客园(cnblogs.com)C#IoC学习笔记-缥缈的尘埃-博客园(cnblogs.com)WPF_SchuylerEX的博客-CSDN博客
绘本讲师训练营【第30期】2/21阅读原创《绘本之力》学习笔记2 郑贤钰
30028郑贤钰今天读了绘本之力《留在灵魂里的东西》读了心里有非常大的感触！两个年幼什么都不懂的孩子，为了自己心爱的东西，攒下来自己的零花钱，却买了一个自己不知道怎么用的东西，当他们觉得这个东西根本就不好，准备扔掉的时候，这是故事中的有趣有爱的老爷爷出现了，帮助孩子们再一次发现之前别人拉出优美的音乐，原来自己买的这一个琴，自认为没用的琴也能够经过老爷爷熟练的演奏也能拉出这样优美的声音，这让孩子们十
仿老师悟耕海者
毕业十年了，今天去拜访老师，看到老师的学习笔记，看到老师努力学习，积极提高的状态，我觉着自己真是有些懈怠了，孩子们，老师的老师都在孜孜不倦，我们岂能偷懒！
C++学习笔记----7、使用类与对象获得高性能（一）---- 书写类（2）王俊山IT c++学习笔记开发语言
2.2、定义成员函数前面对SpreadsheetCell类的定义足以让你生成类的对象。然而，如果想调用setValue()或者getValue()成员函数，连接器就会抱怨这些函数没有定义。这是因为到目前为止，这些成员函数只有原型，而还没有实现。通常，类的定义会在模块接口文件。对于成员函数的定义，你有一个选择：可以在模块定义文件或者在模块实现文件。下面是SpreadsheetCell类，在类内对成员
Spring6学习笔记4：事务 ·云扬· SSM Java #Spring 学习笔记 spring
1JdbcTemplate1.1简介Spring框架对JDBC进行封装，使用JdbcTemplate方便实现对数据库操作准备工作①搭建子模块搭建子模块：spring-jdbc-tx②加入依赖org.springframeworkspring-jdbc6.0.2mysqlmysql-connector-java8.0.30com.alibabadruid1.2.15③创建jdbc.propertie
连通无向图一般中心的算法及其matlab程序详解夏天天天天天天天# 图论算法 matlab 图论
#################本文为学习《图论算法及其MATLAB实现》的学习笔记#################若服务点只允许取在各顶点上,而服务对象却取在各顶点及各边(或弧)上的点,则在所有顶点中选定一个顶点作为图的一般中心其条件是该点离它本身的最远服务对象(包括顶点及各边(或弧)上的点)的距离达到极小值。寻找无向图的一般中心对解决网络最佳服务点确定的问题是十分有效的，使得服务对象的范围
学习笔记：FW内容安全概述 TKE_yinian
内容安全概述信息安全概述主要威胁关于防护简介内容安全威胁应用层威胁内容安全技术WEB安全应用安全入侵防御检测邮件安全数据安全网络安全反病毒全局环境感知沙箱检测信息安全概述•信息安全是对信息和信息系统进行保护，防止未授权的访问、使用、泄露、中断、修改、破坏并以此提供保密性、完整性和可用性。•为关键资产提供机密性、完整性和可用性（CIA三元组）保护是信息安全的核心目标。CIA（Confidential
java的socket实现一个九宫棋游戏睡不醒的小泽
前言一个简单的socket小作品=v=一个机酱在大三实验课中接触到很基础的JAVA语言socket编程。至于你问为什么嵌入式的机酱会弄些Java吗？emmmmm，可能是当初C语言版的不够好玩吧，另外如果碰巧有用，欢迎抱走的yoo在之前的笔记《网络基础知识和网络编程》中有讲解过关于网络编程的一些基本知识，以及一些LinuxC的socket编程，希望粗浅了解socket内部肌理的同学，右转咱的学习笔记
【每日一词】D33 edge 宠辱不惊的中年少女
1）学习笔记：edge：优势，=advantagebeanabsoluteedge有绝对优势AhasanedgeoverB表示A比B更好maintainone'sedge保持优势loseone'sedge失去优势innovativeedge创新方面的优势2）查字典延伸：A.就工作经验而言，她显然要比我们面试过的其他人都胜出一筹。Intermsofexperience,shedefinitelyha
web报表工具FineReport常见的数据集报错错误代码和解释老A不折腾 web报表 finereport 代码可视化工具
在使用finereport制作报表，若预览发生错误，很多朋友便手忙脚乱不知所措了，其实没什么，只要看懂报错代码和含义，可以很快的排除错误，这里我就分享一下finereport的数据集报错错误代码和解释，如果有说的不准确的地方，也请各位小伙伴纠正一下。 NS-war-remote=错误代码\:1117 压缩部署不支持远程设计 NS_LayerReport_MultiDs=错误代码
Java的WeakReference与WeakHashMap bylijinnan java 弱引用
首先看看 WeakReference wiki 上 Weak reference 的一个例子： public class ReferenceTest { public static void main(String[] args) throws InterruptedException { WeakReference r = new Wea
Linux——（hostname）主机名与ip的映射 eksliang linux hostname
一、什么是主机名无论在局域网还是INTERNET上，每台主机都有一个IP地址，是为了区分此台主机和彼台主机，也就是说IP地址就是主机的门牌号。但IP地址不方便记忆，所以又有了域名。域名只是在公网（INtERNET)中存在，每个域名都对应一个IP地址，但一个IP地址可有对应多个域名。域名类型 linuxsir.org 这样的；主机名是用于什么的呢？答：在一个局域网中，每台机器都有一个主
oracle 常用技巧 18289753290
oracle常用技巧 ①复制表结构和数据 create table temp_clientloginUser as select distinct userid from tbusrtloginlog ②仅复制数据如果表结构一样 insert into mytable select * &nb
使用c3p0数据库连接池时出现com.mchange.v2.resourcepool.TimeoutException 酷的飞上天空 exception
有一个线上环境使用的是c3p0数据库，为外部提供接口服务。最近访问压力增大后台tomcat的日志里面频繁出现 com.mchange.v2.resourcepool.TimeoutException: A client timed out while waiting to acquire a resource from com.mchange.v2.resourcepool.BasicResou
IT系统分析师如何学习大数据蓝儿唯美大数据
我是一名从事大数据项目的IT系统分析师。在深入这个项目前需要了解些什么呢？学习大数据的最佳方法就是先从了解信息系统是如何工作着手，尤其是数据库和基础设施。同样在开始前还需要了解大数据工具，如Cloudera、Hadoop、Spark、Hive、Pig、Flume、Sqoop与Mesos。系统分析师需要明白如何组织、管理和保护数据。在市面上有几十款数据管理产品可以用于管理数据。你的大数据数据库可能
spring学习——简介 a-john spring
Spring是一个开源框架，是为了解决企业应用开发的复杂性而创建的。Spring使用基本的JavaBean来完成以前只能由EJB完成的事情。然而Spring的用途不仅限于服务器端的开发，从简单性，可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。其主要特征是依赖注入、AOP、持久化、事务、SpringMVC以及Acegi Security 为了降低Java开发的复杂性，
自定义颜色的xml文件 aijuans xml
<?xml version="1.0" encoding="utf-8"?> <resources> <color name="white">#FFFFFF</color> <color name="black">#000000</color> &
运营到底是做什么的？ aoyouzi 运营到底是做什么的？
文章来源：夏叔叔（微信号：woshixiashushu），欢迎大家关注！很久没有动笔写点东西，近些日子，由于爱狗团产品上线，不断面试，经常会被问道一个问题。问：爱狗团的运营主要做什么？答：带着用户一起嗨。为什么是带着用户玩起来呢？究竟什么是运营？运营到底是做什么的？那么，我们先来回答一个更简单的问题——互联网公司对运营考核什么？以爱狗团为例，绝大部分的移动互联网公司，对运营部门的考核分为三块——用
js面向对象类和对象百合不是茶 js 面向对象函数创建类和对象
接触js已经有几个月了,但是对js的面向对象的一些概念根本就是模糊的,js是一种面向对象的语言但又不像java一样有class,js不是严格的面向对象语言 ,js在java web开发的地位和java不相上下 ,其中web的数据的反馈现在主流的使用json,json的语法和js的类和属性的创建相似下面介绍一些js的类和对象的创建的技术一:类和对
web.xml之资源管理对象配置 resource-env-ref bijian1013 java web.xml servlet
resource-env-ref元素来指定对管理对象的servlet引用的声明，该对象与servlet环境中的资源相关联 <resource-env-ref> <resource-env-ref-name>资源名</resource-env-ref-name> <resource-env-ref-type>查找资源时返回的资源类
Create a composite component with a custom namespace sunjing
https://weblogs.java.net/blog/mriem/archive/2013/11/22/jsf-tip-45-create-composite-component-custom-namespace When you developed a composite component the namespace you would be seeing would
【MongoDB学习笔记十二】Mongo副本集服务器角色之Arbiter bit1129 mongodb
一、复本集为什么要加入Arbiter这个角色回答这个问题，要从复本集的存活条件和Aribter服务器的特性两方面来说。什么是Artiber？ An arbiter does not have a copy of data set and cannot become a primary. Replica sets may have arbiters to add a
Javascript开发笔记白糖_ JavaScript
获取iframe内的元素通常我们使用window.frames["frameId"].document.getElementById("divId").innerHTML这样的形式来获取iframe内的元素，这种写法在IE、safari、chrome下都是通过的，唯独在fireforx下不通过。其实jquery的contents方法提供了对if
Web浏览器Chrome打开一段时间后，运行alert无效 bozch Web chorme alert 无效
今天在开发的时候，突然间发现alert在chrome浏览器就没法弹出了，很是怪异。试了试其他浏览器，发现都是没有问题的。开始想以为是chorme浏览器有啥机制导致的，就开始尝试各种代码让alert出来。尝试结果是仍然没有显示出来。这样开发的结果，如果客户在使用的时候没有提示，那会带来致命的体验。哎，没啥办法了就关闭浏览器重启。结果就好了，这也太怪异了。难道是cho
编程之美-高效地安排会议图着色问题贪心算法 bylijinnan 编程之美
import java.util.ArrayList; import java.util.Collections; import java.util.List; import java.util.Random; public class GraphColoringProblem { /**编程之美高效地安排会议图着色问题贪心算法 * 假设要用很多个教室对一组
机器学习相关概念和开发工具 chenbowen00 算法 matlab 机器学习
基本概念：机器学习(Machine Learning, ML)是一门多领域交叉学科，涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善自身的性能。它是人工智能的核心，是使计算机具有智能的根本途径，其应用遍及人工智能的各个领域，它主要使用归纳、综合而不是演绎。开发工具 M
[宇宙经济学]关于在太空建立永久定居点的可能性 comsci 经济
大家都知道,地球上的房地产都比较昂贵,而且土地证经常会因为新的政府的意志而变幻文本格式........ 所以,在地球议会尚不具有在太空行使法律和权力的力量之前,我们外太阳系统的友好联盟可以考虑在地月系的某些引力平衡点上面,修建规模较大的定居点
oracle 11g database control 证书错误 daizj oracle 证书错误 oracle 11G 安装
oracle 11g database control 证书错误 win7 安装完oracle11后打开 Database control 后，会打开em管理页面，提示证书错误，点“继续浏览此网站”，还是会继续停留在证书错误页面解决办法：是 KB2661254 这个更新补丁引起的，它限制了 RSA 密钥位长度少于 1024 位的证书的使用。具体可以看微软官方公告：
Java I/O之用FilenameFilter实现根据文件扩展名删除文件游其是你 FilenameFilter
在Java中，你可以通过实现FilenameFilter类并重写accept(File dir, String name) 方法实现文件过滤功能。在这个例子中，我们向你展示在“c:\\folder”路径下列出所有“.txt”格式的文件并删除。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
C语言数组的简单以及一维数组的简单排序算法示例，二维数组简单示例 dcj3sjt126com c array
# include <stdio.h> int main(void) { int a[5] = {1, 2, 3, 4, 5}; //a 是数组的名字 5是表示数组元素的个数，并且这五个元素分别用a[0], a[1]...a[4] int i; for (i=0; i<5; ++i) printf("%d\n",
PRIMARY, INDEX, UNIQUE 这3种是一类 PRIMARY 主键。就是唯一且不能为空。 INDEX 索引，普通的 UNIQUE 唯一索引 dcj3sjt126com primary
PRIMARY, INDEX, UNIQUE 这3种是一类PRIMARY 主键。就是唯一且不能为空。INDEX 索引，普通的UNIQUE 唯一索引。不允许有重复。FULLTEXT 是全文索引，用于在一篇文章中，检索文本信息的。举个例子来说，比如你在为某商场做一个会员卡的系统。这个系统有一个会员表有下列字段：会员编号 INT会员姓名
java集合辅助类 Collections、Arrays shuizhaosi888 Collections Arrays HashCode
Arrays、Collections 1 ）数组集合之间转换 public static <T> List<T> asList(T... a) { return new ArrayList<>(a); } a）Arrays.asL
Spring Security（10）——退出登录logout 234390216 logout Spring Security 退出登录 logout-url LogoutFilter
要实现退出登录的功能我们需要在http元素下定义logout元素，这样Spring Security将自动为我们添加用于处理退出登录的过滤器LogoutFilter到FilterChain。当我们指定了http元素的auto-config属性为true时logout定义是会自动配置的，此时我们默认退出登录的URL为“/j_spring_secu
透过源码学前端之 Backbone 三 Model 逐行分析JS源代码 backbone 源码分析 js学习
Backbone 分析第三部分 Model 概述： Model 提供了数据存储，将数据以JSON的形式保存在 Model的 attributes里，但重点功能在于其提供了一套功能强大，使用简单的存、取、删、改数据方法，并在不同的操作里加了相应的监听事件，如每次修改添加里都会触发 change，这在据模型变动来修改视图时很常用，并且与collection建立了关联。
SpringMVC源码总结（七）mvc:annotation-driven中的HttpMessageConverter 乒乓狂魔 springMVC
这一篇文章主要介绍下HttpMessageConverter整个注册过程包含自定义的HttpMessageConverter，然后对一些HttpMessageConverter进行具体介绍。 HttpMessageConverter接口介绍： public interface HttpMessageConverter<T> { /** * Indicate
分布式基础知识和算法理论 bluky999 算法 zookeeper 分布式一致性哈希 paxos
分布式基础知识和算法理论 BY [email protected] 本文永久链接：http://nodex.iteye.com/blog/2103218 在大数据的背景下，不管是做存储，做搜索，做数据分析，或者做产品或服务本身，面向互联网和移动互联网用户，已经不可避免地要面对分布式环境。笔者在此收录一些分布式相关的基础知识和算法理论介绍，在完善自我知识体系的同
Android Studio的.gitignore以及gitignore无效的解决 bell0901 android gitignore
　　github上.gitignore模板合集，里面有各种.gitignore ： https://github.com/github/gitignore 　　自己用的Android Studio下项目的.gitignore文件，对github上的android.gitignore添加了　　　　　　# OSX files　　　　　　//mac os下　　　　　　.DS_Store
成为高级程序员的10个步骤 tomcat_oracle 编程
What 软件工程师的职业生涯要历经以下几个阶段：初级、中级，最后才是高级。这篇文章主要是讲如何通过 10 个步骤助你成为一名高级软件工程师。 Why 得到更多的报酬！因为你的薪水会随着你水平的提高而增加提升你的职业生涯。成为了高级软件工程师之后，就可以朝着架构师、团队负责人、CTO 等职位前进历经更大的挑战。随着你的成长，各种影响力也会提高。
mongdb在linux下的安装 xtuhcy mongodb linux
一、查询linux版本号： lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noa

31天重构学习笔记重新整理下载

前言

目录

代码及PDF下载

你可能感兴趣的:(学习笔记)