How do I begin to write about refactoring? The traditional way to begin talking about something is to outline the history, broad principles, and the like. When someone does that at a conference, I get slightly sleepy. My mind starts wandering with a low-priority background process that polls the speaker until he or she gives an example. The examples wake me up because it is with examples that I can see what is going on. With principles it is too easy to make generalizations, too hard to figure out how to apply things. An example helps make things clear. So I am going to start with an example of refactoring. During the process I will tell you a lot about how refactoring works and give you a sense of the process of refactoring.
I can then provide the usual principles-style introduction. With an introductory example, however, I run into aproblem. If I pick a large program, and describe how it is refactored, it will be too complicated for any reader to work through. However, if I pick a program that is small enough to be comprehensible, refactoring does not look like it is worthwhile. Thus I am in the classic bind of anyone who wants to describe techniques that are useful for realworld programs. Frankly it is not worth the effort to do the refactoring that I am going to show you on a small program like the one I am going to use. But if the code I am showing you is part of a larger system, then the refactoring soon becomes important. So I have to ask you to look at this and imagine it in the context of a much larger system.