What is meant by a step-by-step refactoring plan describing how to
implement a certain design?
As little as I know about refactoring it regards improving a (UML) design model and has nothing to do with the implementation of it. Therefore I’m pretty much confused by what this question means. Does anyone know and willing to explain?
EDIT: In the context the design corresponds to a UML diagram with classes, methods and underlying associations.
2
You questions contains IMHO three misconceptions:
-
“design” does not necessary mean “UML model”. On the contrary, in the context of software development “design” most often just means “the overall structure of a program, program system, or program code”. Parts of that structure can be visualized by UML diagrams, but don’t interchange the visualiziation of a design (UML model) with the design (code structure) itself.
-
“refactoring” means “restructuring an existing body of code, altering its internal structure without changing its external behavior” (cited from http://refactoring.com/). So refactoring has pretty much to do with the implementation of a design in code.
-
“implement a design” does not necessarily mean “coding in green field”. It can also mean “achieve a certain design by any means” (for example, starting with some mediocre designed code and applying refactoring until its structure fits to a design described by a given UML model).
Refactoring can be used to change or improve code to change a code structure (so its design). Ideally this is achieved in many small steps (as opposed to one big “rewrite”). Typically, when doing this, you want to achieve some goal (a better design than before, or a design described with the help of a UML model), so it makes sense to make yourself a plan before you start with the actual refactoring.
For example, lets say you have a class A which has become too big over time and has too many responsibilities. Your goal is to break it down to classes B, C, and D to distribute the responsibilies among them. Before starting with that, you make a plan like this:
- add some unit tests for method A.m1, which calls A.m2 internally.
- add empty class B
- move method m2 from A to B, change A.m1 to call B.m2 instead of A.m2
- run all unit tests to make sure you did not break anything
- add empty class C, and so on
The new class structure of B, C, and D can be described by a UML model, the steps in which order you apply the refactoring to go from A to (B,C,D) have typically to be described separately.
6