Inventory Our refactoring Toolbox

Let's take a look at what's in the System refactoring Toolbox, which is to see how the system is refactored. System refactoring always adjusts our code at different levels, so the refactoring method is divided into several levels. In general, the reconstruction methods are divided into the following levels: reconstruction of methods, reconstruction of objects, reconstruction of objects, reconstruction of inheritance system, reconstruction of organization data and reconstruction of architecture.

We can clearly see the refactoring process of the method in the previous example. The reconstruction of a method often occurs within an object, and is an optimization of an object's interior. From this example, we first see the increase in annotation, adjust the order, rename variables, and so on, and so on, which is not a refactoring method, but it is our usual techniques for preparation. We then extract the individual pieces of code that are stored through the annotation fragment to form a separate function. This refactoring method is called the Extract Method (Extract methods).

Then we continue to refactor. Looking at the program carefully we found that the program was not cohesive. It is best to use a dateutil to manage methods such as Gethour (), to manage various greetings and their rules with greeting, so we did the following refactoring:

/** * A utility about time.
     * @author Fangang */public class Dateutil {/** * get hour of day. * @param date * @return Hour of day */public int gethour (date date) {Calendar calendar = Calendar.g
        Etinstance ();
        Calendar.settime (date);
    Return Calendar.get (Calendar.hour_of_day);
 }/** * All kinds of greeting.
     * @author Fangang/public class Greeting {/** * get the greeting
     * @param user * @return Hi, {user}.
    */public string getfirstgreeting (string user) {return "Hi," +user+ "."
     }/** * Get the second greeting. 
     * @param hour * @return If in the morning, say "good morning!", * If in the afternoon, say "good afternoon!",
     * Else say "good night!". */Public String getsecondgreeting (int hour) {if (hour>=6 && hour<12) {return "good m Orning! ";} else if (hour>=12 && hour<19) {
            Return "Good afternoon!";
        }else{return "Good night!";
     }}/** * The Refactoring ' hello-world program * @author Fangang/public class HelloWorld {/** * Say Hello to everyone * @param now * @param user * @return the words what to Say/public Strin
        G SayHello (Date now, String user) {Dateutil dateutil = new Dateutil ();
            
        int hour = Dateutil.gethour (now);
        Greeting greeting = new greeting ();
    return greeting.getfirstgreeting (user) + greeting.getsecondgreeting (hour); }
}

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

Here we extract the Gethour () from the HelloWorld class and place it in the Dateutil class, leaving only one reference in the HelloWorld class. At the same time, we extract the Getfirstgreeting () and getsecondgreeting () from the HelloWorld class and place them in the greeting class, making the original program into a reference. Such techniques are called "extraction Classes" (Extract Class).

Take a closer look at this procedure:

/**
     * Get the second greeting.
     * @param hour
     * @return If in the morning, say "good morning!", 
     * If in the afternoon, say "good afternoon!", 
     * Else say "good night!".
     */Public
    String getsecondgreeting (int hour) {
        if (hour>=6 && hour<12) {return
            "good morning!";
        }else if (hour>=12 && hour<19) {return
            "good afternoon!";
        } else{return
            "good night!";
        }
    

In addition to morning, afternoon, night, if we increase the evening, the scalability of the program is not good. So we extracted them out of the Greetingrule interface and wrote the implementation classes for morning, afternoon, night, and evening, respectively:

/**
 * Greeting Rules Interface
 * @author Fangang * * Public
interface Greetingrule {
    /**
     * Param Hour * @return whether the ' rule ' right
     *
    /public boolean isright (int hour);
        
    /**
     * @return The greeting words
    /public String getgreeting ();
}
    
/**
 * The greeting in the morning
 * @author fangang/public
class Morninggreeting implements Greeti Ngrule {
    
    /* (non-javadoc)
     * @see Org.refactoring.helloWorld ... Greetingrule#getgreeting ()
     */
    @Override public
    String getgreeting () {return
        "good morning!";
    }
    
    /* (non-javadoc)
     * @see Org.refactoring.helloWorld ... Greetingrule#isright (int)
     */
    @Override public
    boolean isright (int hour) {
        if (hour>=6 & & hour<12) {return
            true;
        }
        return false;
    }
}

Several other implementation classes I am not tired of the slips, and finally the Getsecondgreeting () method changed to this:

/**
     * Get the second greeting.
     * @param hour
     * @return If in the morning, say "good morning!", 
     * If in the afternoon, say "good afternoon!", 
     * If in the evening, say "good evening!",
     * else, say "good night!".
     */Public
    String getsecondgreeting (int hour) {for
        (Greetingrule greetingrule:greetingrules) {
            if ( Greetingrule.isright (hour)) {return
                greetingrule.getgreeting ();
            }
        }
        throw new RuntimeException ("Error when greeting!");
    }

This will be similar, or the same type of code extracted out of the interface, as well as multiple implementations under the interface, we call it "extraction interface (Extract Interface)."

Looking at these examples, you may have a question of whether such a simple procedure is worth it. Yes, well, the structure of the program should be adapted to the complexity of the requirements. Simple requirements to write simple programs, complex requirements to write complex programs. If the simple requirements, in order to play technology, become a complex program, it is "over design." But here in order to more clearly show the refactoring, but also to enable us not to be distracted by complex procedures, so the simple program over the design of a. But as we can see later, when business requirements are becoming more complex, it is worthwhile for us to do these refactoring.

The appendix lists all the refactoring methods that come from refactoring the classic book Refactoring, improving the design of existing code, and we should chew on these methods over time in the future.

As the martial arts master Jin Yong said, "No strokes, no strokes," so many of the refactoring method is not to let you go mechanically, but should be a deep understanding of it, eventually become your own reconstruction method. We do not care too much in the actual work we use what refactoring method, which refactoring is used in which method, as long as the appropriate design is OK. However, in the absence of strokes, we must have a recruit, that is, learned, understand the various moves, in the actual work you can think of these moves, to use these moves. Learning and practice are always two complementary and mutually reinforcing processes.

However, the system reconstructs a number of classic books, guiding our practice is not many books. Believe that there are many people with lofty ideals, in the reading of the books after the excessive, passionate, blood surging, but back to the real world, back to the actual work but at a loss, after a struggle, and then forget. Therefore, this book will start from the practice, with practical work examples, with a more realistic perspective to show you how the system refactoring is how to guide our work, so that we really use.