Rebuild serialization 8: review our refactoring toolbox

Labels: Software Design agility

Next, let's take a look at what is in the System Reconstruction toolbox, that is, to see what methods are available for system reconstruction. System refactoring always adjusts our code at different levels, so the refactoring method is divided into multiple layers. In general, the reconstruction methods are divided into the following layers: reconstruction of methods, objects, objects, inheritance systems, organization data, and architecture.

In the previous example, we can clearly see the reconstruction process of the method. Method refactoring usually occurs inside an object, which is an optimization of an object. In this example, we first see operations such as adding comments, adjusting the order, renaming variables, and performing segments. Although these operations are not a refactoring method, they are common techniques for our preliminary preparation. Then we will extract the segments stored in comments to form separate functions. This refactoring method is called "extract method )".

Then we continue to refactor. Looking at this program, we find that this program is not cohesive. It is best to use a dateutil method to manage methods such as gethour () and use greeting to manage various greetings and their rules. Therefore, we have reconstructed the following:

/** * 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.getInstance();calendar.setTime(date);return calendar.get(Calendar.HOUR_OF_DAY);}}/** * All kinds of greeting. * @author fangang */public class Greeting {/** * Get the first 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 morning!";}else if(hour>=12 && hour<19){return "Good afternoon!";}else{return "Good night!";}}}/** * The Refactoring's hello-world program * @author fangang */public class HelloWorld {/** * Say hello to everyone * @param now * @param user * @return the words what to say */public String 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);}}

Here we extract gethour () from the helloworld class and place it in the dateutil class so that only one reference is retained in the helloworld class. At the same time, we extract getfirstgreeting () and getsecondgreeting () from the helloworld class and place them in the greeting class so that the original program becomes a reference. This technique is called "extract class )".

Then observe the procedure carefully:

/** * 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!";}}

Except for morning, afternoon, and night, if we increase evening, the scalability of the program will be poor. Therefore, we extract the greetingrule interfaces and write the implementation classes of morning, afternoon, night, and evening respectively:

/** * Greeting rules interface * @author fangang */public interface GreetingRule {/** * @param hour * @return whether the rule is right */public boolean isRight(int hour);/** * @return the greeting words */public String getGreeting();}/** * The greeting in the morning * @author fangang */public class MorningGreeting implements GreetingRule {/* (non-Javadoc) * @see org.refactoring.helloWorld...GreetingRule#getGreeting() */@Overridepublic String getGreeting() {return "Good morning! ";}/* (non-Javadoc) * @see org.refactoring.helloWorld...GreetingRule#isRight(int) */@Overridepublic boolean isRight(int hour) {if(hour>=6 && hour<12){return true;}return false;}}

I don't have to worry about the other implementation classes. I finally changed the getsecondgreeting () method to this:

<span style="white-space:pre"></span>/** * 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 method extracts similar or similar code to form an interface and multiple Implementations under the interface, which is called "extract interface )".

After reading these examples, you may have a question: Is it worthwhile to make such a simple program? Yes, good. The program structure should be adapted to the complexity of requirements. Simple requirements compile simple programs, complex requirements compile complex programs. If you build complex programs for technical purposes with simple requirements, it is "over-design ". However, to better demonstrate refactoring, we can avoid being distracted by complicated programs, so we have over-designed simple programs. However, we can see that when the business needs become more complex, it is worth doing the above reconstruction.

The appendix below lists all refactoring methods, all of which come from refactoring the classic book refactoring to improve the design of existing code. We should chew on these methods again and again in the future.

As Jin Yong, a martial arts master, said, "No tricks, no tricks, no tricks." There are so many reconstruction methods that you should not be able to learn, but should be deeply understood, eventually it becomes your own refactoring method. In our actual work, do not worry too much about what reconstruction method we use and which method is used, as long as it is a suitable design. However, before we can win or win, we must have some moves, that is, we have learned and understood various moves. In actual work, you can think of these moves and use them. Learning and practice are always complementary and mutually reinforcing processes.

However, there are a lot of classic books for system restructuring, but there are not many books to guide us in practice. I believe that there are many people with lofty ideals. After reading the restructured books, I am passionate and enthusiastic. But when I return to the real world, I am at a loss in my work. After some hard struggles, I will give up on it. Therefore, this book will begin with practice and use examples in actual work to show you how system restructuring guides us in our work, so that we can truly use it.

Big talk rebuilding serialization home: http://blog.csdn.net/mooodo/article/details/32083021

Note: I hope that the author or source should be noted to show my respect for the author when I reprint this article. Thank you!