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'm going to start this book with an example of refactoring. During the process I'll 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 a big problem. If I pick a large program, describing it and how it is refactored is 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'm going to show you on a small program like the one I'm 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.
In this definition the user interface contains the screen elements needed to obtain the user input and the logic to prevent unlimited attempts.
Security Client Application
The client application knows what database to access and how to lookup the user. Changing the security database to another database engine would require significant changes to the client application.