Method Learning of Java code refactoring

2,8 Reading

Chapter One first case

Used in this case,

Methods of extraction (extract method), methods of Moving (Move method), elimination of temporary variables, variable and function name refactoring, switch type refactoring (replace type code with State/strategy), and so on.

Refactoring makes code functionality more reusable, and is biased against maintenance and modification.

Attention:

The properties of the switch statement try not to be the data of another object, preferably on your own data

Chapter II Reconstruction Principles

How to Refactor: (noun) without changing the observable behavior of the software, provide understandable, reduce its cost of modification.

How to Refactor: (verb) Use a series of refactoring methods to change the structure without changing the observable behavior of the software.

Refactoring can help us find bugs and improve programming speed.

When to refactor:

Refactoring is not refactoring for refactoring, refactoring should be done anytime, anywhere, because refactoring can help you do things better when you want to do something else.

For the first time in the three rules, if you do something like this for the second time, you'll be tired of doing similar things, and the third time doing something like this is going to be reconstructed. (Charm, three refactoring).

Refactoring is needed when we add new features, which can help us understand the previous code more deeply.

Refactoring when we fix bugs can help us to better understand the code and find problems or bugs.

When we review the code, refactoring is needed to help improve the team's development, facilitate the spread of knowledge, and make the code clearer and easier to understand.

When not to refactor: The code is too messy and full of errors, which we can choose to rewrite.

Refactoring and Design: a good design in the early stages can help us save on the high cost of rework.

Performance optimization: Code post-Maintenance is appropriate, optimized for programs that feature during the late run, because most of the code is not often executed, and the optimization is of little significance.

Chapter III Bad taste of code

Code use time: 1. Duplicate code uses the Extract method. 2. Two or more subclasses use the same method to push them into a into hyperspace class. 3. Similar code can use the template method.

4. Duplicate code in two unrelated classes, refining it out into a separate class.

Long function: A function with short objects will be better.

Oversized classes: If you do too many things with one class, you tend to have too many instance variables, and once that happens, duplicate code will follow.

Long parameter columns: You can use objects in place of too-long parameters.

Divergent change divergence: A class that changes in different directions for different reasons is understood here as the principle of cohesion-poly-low coupling.

Shotgun Surgery (Shotgun modified): Contrary to divergent change, there are many minor changes that need to be made within many different classes when each encounter changes, and the method of change needs to be

Move to the same class.

Feature Envy (attachment complex): When a function's interest in a class is higher than its own class, when a function calls another object's half-dozen function in order to calculate a data value,

We need to move this method into the attachment class. Sometimes the function is only partially dependent, and it needs to be extracted before moving.

Data clumps: If there are too many duplicate data in the fields or functions of multiple classes, consider refining them into a new class.

Basic type bigotry: You can replace the base type with an object form.

Switch Surprise shu: Use the switch statement as little as possible to convert it to polymorphic.

Parallel inheritance system: for example, when multiple superclass prefixes are named very similar, consider whether there is cohesion clustering problem. You can then move the method to merge the duplicated superclass.

Lazy class Redundancy: If a class is almost inapplicable, or if it was originally designed to deal with a change, and the change doesn't happen again, consider the inline class.

Speculative generality rhetoric of the future: Redundant abstract classes, parameters, functions and other practical inline class.

Temporary field is a confusing temporary variable: You can extract temporary variables that are specific to a new class and move the relevant methods past.

Messages chains over-coupled message chain: If you find that one object calls another object, another object calls another object, a long list of call chains appears,

Changing any one of these classes will cause the client to make the appropriate modifications.

Too many comments: do not abuse annotations.

The fourth chapter constructs the test system

Testing can help us find bugs in the system and enable us to understand the design ideas of the project in greater depth. A good test system is the foundation to help us restructure, step by step.

Fifth Chapter Refactoring List

This paper mainly describes the author's practice of reconstructing various techniques. The standard described is "name; summary; motive; how does the result solve the problem after the reconstruction?"

Sixth chapter re-organization function

6.1 Extract Method Refinement function

Motivation: The greater the fine granularity of the function, the higher the chance of being reused, the clearer the name of the function, and the easier it is to be understood.

6.9 Replacement algorithm

String Foundperson (string[] people) {

for (int i=0;i<people.length;i++) {

if (People[i].equals ("Don")) return "Don";

if (People[i].equals ("John")) return "John";

if (people[i].equals ("Kent")) return "Kent";

}

return "";

}

String Foundperson (string[] people) {

List candidates = arrays.aslist (new string[]{"Don", "John", "Kent"});

for (int i=0;i<people.length;i++) {

if (Candidates.contains (People[i]))

{

return people[i];

}

}

return "";

}

Method Learning of Java code refactoring