Refactoring
No design is perfect. During implementation, you may discover that your design needs change for a number of reasons. Most notably, a new requirement may arrive or a flaw in the current design may be discovered. Refactoring is the process by which we change the design of code without affecting its behavior. Once the design has been updated, implementation may proceed.
A great many common refactorings appear in Martin Fowler’s book, Refactoring: Improving the Design of Existing Code. The following are links to third-party summaries of the refactorings we will discuss throughout this course.
- Extract Method
- Inline Method
- Inline Temp
- Replace Temp With Query
- Replace Method With Method Object
- Move Method
- Move Field
- Extract Class
- Inline Class
- Encapsulate Field
- Replace Type Code with State/Strategy
- Replace Conditional With Polymorphism
- Introduce Assertion
- Replace Parameter With Explicit Methods
- Introduce Parameter Object
- Collapse Hierarchy
- Form Template Method
- Replace Inheritance With Delegation
- Replace Delegation With Inheritance
Refactorings are commonly identified as a result of code smells. The linked Wikipedia article contains a number of common code smells; it’s good to be familiar with them.
There is no single authoritative list of all refactorings or code smells, although some refactorings and smells are prominent enough to have de facto names. The above-linked refactorings and code smells are common to object-oriented languages but may not be applicable to every language. What constitutes a code smell in one language may be standard practice in another. As a software engineer, your goal is to learn the best practices in the language in which you’re working and develop an eye for bad code or design.