Refactoring

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m
 
(10 intermediate revisions by 5 users not shown)
Line 4: Line 4:
 
:''Refactoring (verb)'': to restructure software by applying a series of refactorings without changing its observable behaviour.
 
:''Refactoring (verb)'': to restructure software by applying a series of refactorings without changing its observable behaviour.
  
Both of these definitions carry a common line: "without changing its observable behaviour". Refactoring is the process of restructuring code to make it easier to use, cleaner to work with, and removing [[Code smells]].
+
Both of these definitions carry a common line: "without changing its observable behaviour". Refactoring is the process of restructuring code to make it easier to use, cleaner to work with, and removing [[Code smells]]. An alternative definition is "Extending a program to make it more extensible".
  
 
== Discussion ==
 
== Discussion ==
Refactoring is is a big deal. It overturns the older culture of [[If it ain't broke don't fix it]] by allowing developers to change code to meet their own needs, rather than for fixing bugs or adding features. It is an integral part of [[Agile methods]].
+
Refactoring is a big deal. It overturns the older culture of [[If it ain't broke don't fix it]] by allowing developers to change code to meet their own needs, rather than for fixing bugs or adding features. It is an integral part of [[Agile methods]], expecially [[Test Driven Development]].
  
 
Refactoring is much more disciplined than just editing code. It is an anti-hacking practice that reduces code changes to simple, atomic transactions. [[Martin Fowler 1999]] says "the cumulative effect of these small changes can radically improve the design".  
 
Refactoring is much more disciplined than just editing code. It is an anti-hacking practice that reduces code changes to simple, atomic transactions. [[Martin Fowler 1999]] says "the cumulative effect of these small changes can radically improve the design".  
Line 13: Line 13:
 
According to [[Martin Fowler 1999]], p. xvii, [[Kent Beck]] is the foremost "master of the art" of refactoring. Beck has opinions about [[Why refactoring works]].  
 
According to [[Martin Fowler 1999]], p. xvii, [[Kent Beck]] is the foremost "master of the art" of refactoring. Beck has opinions about [[Why refactoring works]].  
  
Refactoring is heavily dependent on [[Unit testing]]. Before any code is refactored, a test suite should be developed. It is used to check that the refactoring didn't break anything. If you are performing a series of small refactorings, run the tests between each one. This makes it easy to identify & fix bugs immediately.  
+
Refactoring is heavily dependent on [[Unit testing]]. Before any code is refactored, a self-checking test suite should be developed. It is used to check that the refactoring didn't break anything. If you are performing a series of small refactorings, run the tests between each one. This makes it easy to identify & fix bugs immediately. Fowler states that, when refactoring, one needs to know what can go wrong, and figure out how to refactor the program safely, with [[Martin Fowler 1999]] providing safe steps for the various types of refactoring.
  
 
The culture of refactoring says that, if you are looking at some code and you see a way to make it better, you should. You should also refactor if you can't understand what it does. Fowler argues that this [[Refactoring and design]] approach makes a big difference to design culture.  
 
The culture of refactoring says that, if you are looking at some code and you see a way to make it better, you should. You should also refactor if you can't understand what it does. Fowler argues that this [[Refactoring and design]] approach makes a big difference to design culture.  
  
Fowler also discusses [[Refactoring and performance]].  
+
Fowler also discusses [[Refactoring and performance]].
  
 
==Refactoring Techniques==
 
==Refactoring Techniques==
 +
 +
These techniques are from [[Martin Fowler 1999]]. There are more techniques [http://refactoring.com/catalog/index.html here (refactoring.com)].
 +
 
===Composing Methods===
 
===Composing Methods===
 
[[Extract Method]]
 
[[Extract Method]]
Line 121: Line 124:
  
 
[[Introduce Parameter Object]]
 
[[Introduce Parameter Object]]
 
[[Replace Parameter Object]]
 
  
 
[[Remove Setting Method]]
 
[[Remove Setting Method]]
Line 136: Line 137:
 
[[Replace Exception with test]]
 
[[Replace Exception with test]]
  
===Dealing with Genralisation===
+
===Dealing with Generalisation===
 
[[Pull Up Field]]
 
[[Pull Up Field]]
  
Line 167: Line 168:
  
 
[[Extract Hierarchy]]
 
[[Extract Hierarchy]]
 
<u>'''Thats just the ones from [[Martin Fowler 1999]] There are more some of them are up [http://refactoring.com/catalog/index.html here (refactoring.com)]'''</u>
 
  
 
== Notes ==
 
== Notes ==
Line 179: Line 178:
 
== See also ==
 
== See also ==
 
* [[Ward's wiki]] pages:
 
* [[Ward's wiki]] pages:
** [[http://c2.com/cgi/wiki?WhatIsRefactoring WhatIsRefactoring]]
+
** [http://c2.com/cgi/wiki?WhatIsRefactoring WhatIsRefactoring]
** [[http://c2.com/cgi/wiki?RefactorMercilessly RefactorMercilessly]]
+
** [http://c2.com/cgi/wiki?RefactorMercilessly RefactorMercilessly]
** [[http://c2.com/cgi/wiki?WikiPagesAboutRefactoring WikiPagesAboutRefactoring]]
+
** [http://c2.com/cgi/wiki?WikiPagesAboutRefactoring WikiPagesAboutRefactoring]
** [[http://refactoring.com/ Refactoring.com]] Maintained by [[Martin Fowler]]  
+
** [http://refactoring.com/ Refactoring.com] Maintained by [[Martin Fowler]]  
 
* Refactoring humour:
 
* Refactoring humour:
** [[http://www.waterfall2006.com/gorman.html Refuctoring & Code Smiles]]
+
** [http://www.waterfall2006.com/gorman.html Refuctoring & Code Smiles]
** [[http://mindprod.com/jgloss/unmain.html Writing unmaintainable code]]
+
** [http://mindprod.com/jgloss/unmain.html Writing unmaintainable code]
 
* [[Martin Fowler 1999]]
 
* [[Martin Fowler 1999]]
 
* [[Code smells]]
 
* [[Code smells]]
 +
 +
{{Refactoring}}

Latest revision as of 08:51, 16 December 2011

Martin Fowler 1999 defines refactoring in two ways---in the noun form, and the verb form:

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour.
Refactoring (verb): to restructure software by applying a series of refactorings without changing its observable behaviour.

Both of these definitions carry a common line: "without changing its observable behaviour". Refactoring is the process of restructuring code to make it easier to use, cleaner to work with, and removing Code smells. An alternative definition is "Extending a program to make it more extensible".

Contents

Discussion

Refactoring is a big deal. It overturns the older culture of If it ain't broke don't fix it by allowing developers to change code to meet their own needs, rather than for fixing bugs or adding features. It is an integral part of Agile methods, expecially Test Driven Development.

Refactoring is much more disciplined than just editing code. It is an anti-hacking practice that reduces code changes to simple, atomic transactions. Martin Fowler 1999 says "the cumulative effect of these small changes can radically improve the design".

According to Martin Fowler 1999, p. xvii, Kent Beck is the foremost "master of the art" of refactoring. Beck has opinions about Why refactoring works.

Refactoring is heavily dependent on Unit testing. Before any code is refactored, a self-checking test suite should be developed. It is used to check that the refactoring didn't break anything. If you are performing a series of small refactorings, run the tests between each one. This makes it easy to identify & fix bugs immediately. Fowler states that, when refactoring, one needs to know what can go wrong, and figure out how to refactor the program safely, with Martin Fowler 1999 providing safe steps for the various types of refactoring.

The culture of refactoring says that, if you are looking at some code and you see a way to make it better, you should. You should also refactor if you can't understand what it does. Fowler argues that this Refactoring and design approach makes a big difference to design culture.

Fowler also discusses Refactoring and performance.

Refactoring Techniques

These techniques are from Martin Fowler 1999. There are more techniques here (refactoring.com).

Composing Methods

Extract Method

Inline Method

Inline Temp

Replace Temp with Query

Introduce Explaining Variable

Split Temporary Variable

Remove assignments to Parameters

Replace Method with Method Object

Substitute Algorithm

Moving Features Between Objects

Move Method

Move Field

Extract Class

Inline Class

Hide Delegate

Remove Middle Man

Introduce Foreign Method

Introduce Local Extension

Organising Data

Self Encapsulate Field

Replace Data Value with Object

Change Value to Reference

Change Reference to Value

Replace Array with Object

Duplicate Observed Data

Change Unidirectional Association to Bidirectional

Change Bidirectional Association to Unidirectional

Replace Magic Number with Symbolic Constant

Encapsulate Field

Encapsulate Collection

Replace Type Code with Class

Replace Type Code with Subclass

Replace Type Code with State/Strategy

Simplifying Conditional Expressions

Decompose Conditional

Consolidate Conditional Expression

Consolidate Duplicate Conditional Fragments

Remove Control Flag

Replace Nested Conditional with Guard Clauses

Replace Conditional with Polymorphism

Introduce Null Object

Introduce Assertion

Making Method Calls Simpler

Rename Method

Add Parameter

Remove Parameter

Separate Query from Modifier

Parameterise Method

Replace Parameter with Explicit Methods

Preserve Whole Object

Replace Parameter with Method

Introduce Parameter Object

Remove Setting Method

Hide Method

Replace Constructor with Factory Method

Encapsulate Downcast

Replace Error Code with Exception

Replace Exception with test

Dealing with Generalisation

Pull Up Field

Pull Up Method

Pull Up Constructor Body

Push Down Field

Push Down Method

Extract Subclass

Extract Superclass

Extract Interface

Collapse Hierarchy

Form Template Method

Replace Inheritance with Delegation

Big Refactorings

Tease Apart Inheritance

Convert Procedural Design to Objects

Separate Domain from Presentation

Extract Hierarchy

Notes

See also


Refactoring

Composing Methods: Extract Method | Inline Method | Inline Temp | Replace Temp with Query | Introduce Explaining Variable | Split Temporary Variable | Remove assignments to Parameters | Replace Method with Method Object | Substitute Algorithm
Moving Features Between Objects: Move Method | Move Field | Extract Class | Inline Class | Hide Delegate | Remove Middle Man | Introduce Foreign Method | Introduce Local Extension
Organising Data: Self Encapsulate Field | Replace Data Value with Object | Change Value to Reference | Change Reference to Value | Replace Array with Object | Duplicate Observed Data | Change Unidirectional Association to Bidirectional | Change Bidirectional Association to Unidirectional | Replace Magic Number with Symbolic Constant | Encapsulate Field | Encapsulate Collection | Replace Type Code with Class | Replace Type Code with Subclass | Replace Type Code with State/Strategy
Simplifying Conditional Expressions: Decompose Conditional | Consolidate Conditional Expression | Consolidate Duplicate Conditional Fragments | Remove Control Flag | Replace Nested Conditional with Guard Clauses | Replace Conditional with Polymorphism | Introduce Null Object | Introduce Assertion
Making Method Calls Simpler: Rename Method | Add Parameter | Remove Parameter | Separate Query from Modifier | Parameterise Method | Replace Parameter with Explicit Methods | Preserve Whole Object | Replace Parameter with Method | Introduce Parameter Object | Replace Parameter Object | Remove Setting Method | Hide Method | Replace Constructor with Factory Method | Encapsulate Downcast | Replace Error Code with Exception | Replace Exception with test
Dealing with Generalisation: Pull Up Field | Pull Up Method | Pull Up Constructor Body | Push Down Field | Push Down Method | Extract Subclass | Extract Superclass | Extract Interface | Collapse Hierarchy | Form Template Method | Replace Inheritance with Delegation
Big Refactorings: Tease Apart Inheritance | Convert Procedural Design to Objects | Separate Domain from Presentation | Extract Hierarchy

Personal tools