More About Prefactoring and Model Refactoring

Refactoring means improving the design without changing the functionality. It generally refers to changes made to the source code; unit tests are used to ensure that the functionality hasn’t changed while the code is being refactored.

Model refactoring means changing the design at the object modeling stage, prior to coding, without changing the functionality. Unit tests aren’t really applicable at this level because we’re not dealing with code yet. (Of course, we should still write unit tests when we do get to coding. See Chapters 12 for some examples of how to drive unit testing from the object model.)

Model refactoring affects the class diagrams (i.e., the structure of the code) and is driven by both the robustness diagram and the sequence diagram. Robustness diagrams serve a dual purpose: disambiguation of requirements and object discovery. Sequence diagrams focus on making a clean allocation of functions to classes (aka behavior allocation or prefactoring, which we can define as getting the factoring of methods to classes right the first time instead of relying on refactoring to get it right). We try to discover all the classes we need first (using robustness diagrams) and then decide how the behavior is accomplished by the participating objects during detailed design (using sequence diagrams). So we have two distinct diagrams for two distinct thought processes.

Object discovery (on robustness diagrams) can be thought of as conceptual design. It involves manipulation of the (still fluid) object model at the conceptual level of abstraction, without worrying too much about implementation details. We’re basically analyzing the behavior of a use case, trying to determine whether our current set of classes is sufficient to handle the required behavior, and adding new classes if they’re needed.

Prefactoring, or behavior allocation, really gets at the essence of detailed OO design.^[9.] Prefactoring involves identifying which class should be responsible for each software function by drawing messages between objects on sequence diagrams and assigning operations to classes as we diagram out the message passing. Doing a good job of prefactoring the design minimizes the need for Constant Refactoring After Programming.

^[9.]An excellent reference on this thought process is the book on Responsibility-Driven Design by Rebecca Wirfs-Brock, Brian Wilkerson, and Laura Wiener titled Designing Object-Oriented Software (Upper Saddle River, NJ: Prentice-Hall, 1990). A good “capsule summary” way to think about the responsibility-driven thought process (taught to Doug many years ago by Dan Rawsthorne) is this: think of each object as having a personality, and try to avoid schizophrenic objects. Another useful thought is to put the functions where the data lives.