| When we refactor, we're trying to respond to the forces affecting code. Sometimes what was a good change today no longer looks so good tomorrow, and we find ourselves reversing a refactoring. | Interlude I2.1 | Table I-3 presents a list of refactorings. Next to each refactoring, write the name of the refactoring that undoes its effects. (The refactoring and its inverse will both be on the list.) See Appendix C for solution. | Table I.3. Refactorings and Their Inverses | REFACTORING | INVERSE | | Add Parameter | | | Change Bidirectional Association to Unidirectional | | | Change Reference to Value | | | Change Unidirectional Association to Bidirectional | | | Change Value to Reference | | | Collapse Hierarchy | | | Extract Class | | | Extract Method | | | Extract Subclass | | | Hide Delegate | | | Inline Class | | | Inline Method | | | Inline Temp | | | Introduce Explaining Variable | | | Move Field | | | Move Method | | | Parameterize Method | | | Pull Up Field | | | Pull Up Method | | | Push Down Field | | | Push Down Method | | | Remove Middle Man | | | Remove Parameter | | | Rename Method | | | Replace Delegation with Inheritance | | | Replace Inheritance with Delegation | | | Replace Parameter with Explicit Methods | | | Substitute Algorithm | | |