# Refactoring

## What is Refactoring?

>The external behavior of the system does not change while the internal structure of the system is improved.

Sometimes called "Improving the design after it has been written" or "Improving the design of existing code",the purpose is to make software easier to understand and modify

+ **Benefits**
    + Code size **reduced** after refactoring
    + Confusing structures are transformed into **simpler** structures(Easier to maintain)


+ **How to make refactoring safe?**
    + Use refactoring "patterns"
    + Test constantly,write test before write code,and after refactoring,run the tests and check they all pass.

## Why should you refactor?

- Improve the design of software
- Makes software easier to understand
- Helps find bugs
- Helps program faster

## When should you refactor?

- First,`The rule of three`:three strikes of duplication.
- Second,refactor when you add functionality.You can do it before or after adding the function.(Easier to add function or clean up the code after adding)
- Third,do it when you need to fix a bug.
- Last,refactor as you do a code review.

## Still some problems...

- Database is not easy to be refactored.
- Some refactorings may require the change of interfaces,which is not allowed for those which have been published.
- Major design changes cannot be accomplished via refactoring.

## Where to start?

*Look for "Bad smells" in code.*

### Duplicated code
Bad because if you modify one instance of duplicated code but not the others, you (may) have introduced a bug!(修改一个地方代码但是别的没改，可能引入错误)

### Long Method
Long methods are more difficult to understand

### Large Class
Large classes try to do too much, which reduces cohesion（上帝类，Activity类，职责太多）

### Long Parameter List
Hard to understand, can become inconsistent if the same parameter chain is being passed from method to method（参数过长的方法容易导致不一致性，想想starbucks项目的drawChart模块）

### Divergent Change
- Symptom: one type of change requires changing one subset of methods; another type of change requires changing another subset（一种原因修改代码中的一部分方法，另一种原因修改另一部分，则其实可以分成两个类）
- Related to cohesion

### Shotgun Surgery
A change requires lots of little changes in a lot of different classes（导致大量不同类的大量小修改）

### Feature Envy
A method requires lots of information from some other class（倒不如一开始就给它，也就是将它移动到依赖的那个类中去）

### Data Clumps
Attributes that clump together (are used together) but are not part of the same class

### Primitive Obsession
characterized by a reluctance to use classes instead of primitive data types（使用太多的原始类型而不是类对象）

### Switch Statements
Switch statements are often duplicated in code; they can typically be replaced by use of polymorphism (let OO do your selection for you!)（使用多态替换switch）

### Parallel Inheritance Hierarchies
Similar to Shotgun Surgery; each time I add a subclass to one hierarchy, I need to do it for all related hierarchies
Note: some design patterns encourage the creation of parallel inheritance hierarchies （比如工厂模式）

### Lazy Class
A class that no longer "pays its way"（留着是祸害，坏处大于好处）

### Speculative Generality
"Oh I think we need the ability to do this kind of thing someday"（预先设想的功能并没有发生）

### Temporary Field
An attribute of an object is only set/used in certain circumstances;
but an object should need all of its attributes（为了特定需求而给类弄的一次性属性其实并不需要）

### Message Chains
A client asks an object A for another object B and then asks that object B for another object C etc. Bad because client depends on the structure of the navigation（绕圈子才能获得想要的东西就会使客户产生对导航结构的依赖）

### Middle Man
If a class is delegating more than half of its responsibilities to another class, do you really need it? Involves trade-offs, some design patterns encourage this (e.g. Decorator)（专门分派工作给别人做，自己却几乎不做什么）

### Inappropriate Intimacy
Pairs of classes that know too much about each other’s implementation details (loss of encapsulation; change one class, the other has to change)（一对类知道太多互相的实现细节）

### Data Class (information holder)
These are classes that have fields, getting and setting methods for the fields, and nothing else; they are data holders, but objects should be about data AND behavior（除了信息什么也没有，换句话说这个类没有行为，只是持有数据）

### Refused Bequest
A subclass ignores most of the functionality provided by its superclass
Subclass may not pass the “IS-A” test（子类几乎不用父类继承下来的东西，这样实际不能成为继承关系）

### Comments
Comments are sometimes used to hide bad code（隐藏了臭味）

## Introducing common methods to refactor

- Extract method
- Replace Temp with Query
- Move method
- Replace Conditional with polymorphism
- Introduce Null Object
- Separate Query for Modifier
- Introduce Parameter Object
- Encapsulate Collection
- Replace Nested Conditional with Guard Clauses

### Extract method（方法抽取，隔离变化，针对接口编程）
You have a code fragment that can be grouped together
Turn the fragment into a method whose name explains the purpose of the fragment

### Replace Temp with Query（使用函数调用代替临时变量）
You are using a temporary variable to hold the result of an expression，
Extract the expression into a method;
Replace all references to the temp with the expression.
The new method can then be used in other methods

### Move method（高内聚，低耦合）
A method is using more features (attributes and operations) of another class than the class on which it is defined（如果特性羡慕，那么移动到使用最多的属性和方法的类）

Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether

When moving a method to a new class, we examine its code to see if makes use of internal attributes of its original class

All such attributes become parameters to the method in its new home. (If the method already had parameters, the new parameters get tacked on to the end of its existing parameter list.)

### Replace Conditional with polymorphism（封装的思想）
You have a conditional that chooses different behavior depending on the type of an object

Move each "leg" of the conditional to an overriding method in a subclass.
Make the original method abstract（子类实现不同的'条件'）

### Introduce Null Object（考虑封装成一个对象，而不是用一堆的null判断）
Repeated checks for a null value

Rather than returning a null value ， return an instance of a "null custom" object

### Separate Query for Modifier（查询与修改分离）
Sometimes you will encounter code that does something like this
`getTotalOutstandingAndSetReadyForSummaries()`

It is a query method but it is also changing the state of the object being called

This change is known as a "side effect" because it’s not the primary purpose of the method

It is generally accepted practice that queries should not have side effects so this refactoring says to split methods like this into:

```
getTotalOutstanding()
setReadyForSummaries()
```

Try as best as possible to avoid side effects in query methods

### Introduce Parameter Object
You have a group of parameters that go naturally together，stick them in an object and pass the object

Imagine methods like
```
amountInvoicedIn(start: Date; end: Date);
amountOverdueIn(start: Date; end: Date);
```
This refactoring says replace them with something like
`amountInvoicedIn(dateRange: DateRange)`

The new class starts out as a data holder but will likely attract methods to it

### Encapsulate Collection（封装具体实现细节，提高效率，减少依赖性）
A method returns a collection,make it return a read-only version of the collection and provide add/remove methods

### Replace Nested Conditional with Guard Clauses
This refactoring relates to the purpose of conditional code

One type of conditional checks for a variation in "normal" behavior

The other type of conditional checks for unusual circumstances that require special behavior;

if all of these checks fail then the system proceeds with "normal behavior"

With the refactoring, all of the code trying to identify special conditions are turned into one-line statements that determine whether the condition applies and if so handles it,that’s why these statements are called "guard clauses"

Sometimes complex compound conditionals can be converted into guard clauses by reversing the condition that is being tested,by reversing the conditionals and "failing early" you simplify the code（更早失败，简化代码）