Welcome to reprint, reprint please indicate the original author and source
Recently, while extending an existing project, I found a class to change that was 766 lines long and opened nearly 40 public interfaces. I finished it in tears. In order to prevent this kind of tragedy from happening to me again, I think it is necessary to write a blog to let the general programming people know the importance of code refactoring
If you know an ape who writes thousands of lines, be sure to pass this on to him or her
Why can’t classes be too long?
Class too long — unreadable and unextensible
- Unreadable – it takes several seconds to scroll directly, and even the original author may not be able to sort out the entire class, let alone other readers
- Unextensibility – A class with too many interfaces can be extremely difficult to extend, with thousands of lines
Classes are too long — there may be redundant code
At this point, the CV engineer shuddered
Redundant code, which is duplicate code, is usually produced by CV engineers who use Ctrl+C, Ctrl+V to produce code. Redundant code is very harmful:
- Redundant code makes methods and classes too long and not concise
- Redundant code causes divergent changes (when redundant code needs to be changed, Ctrl+V needs to be changed everywhere)
Classes are too long — probably too many responsibilities
A class opens dozens of interfaces, and there is definitely a problem of too many responsibilities. Just like Tom in the picture, there is also a huge problem of too many responsibilities for a class:
-
Violation of design principle, the single responsibility principle (single responsibility principle requires a class only a duty, such as sweeping, wipe a Tom only do one thing of table and mop the floor, and the realization of the other things can be transferred to the history of parker dog or obese maid), violation of this principle can lead to divergent type change, the divergent type change, class code problems such as too long, It also makes your classes hard to extend, and may even make other programmers think you’re unprofessional
-
If a class has a lot of responsibilities, it must have a lot of fan-ins (callers). Changes made by each caller may force the class to change accordingly. This is called a divergent change
So wherever something goes wrong, your class suffers
-
Similarly, if a class has a lot of responsibilities, it must have a lot of fan-outs (callers) to support its implementation. If this kind of logic changes, all the callers may have to change with it, also known as divergent changes
So if you have a problem with your class, it will happen everywhere
-
Hard to extend: If you have a class with a lot of interfaces, what about its subclasses? What about its wrapper class? Do all implement so many interfaces, and all have the same amount of responsibility? It’s really cumbersome to scale
-
Trigger mechanism: [Anger of testing] [Anger of Operation and Maintenance]
I’ve already written thousands of lines. What do I do?
Refactoring — Extracting redundant code
To extract redundant code is to extract the duplicate code into a separate method, and then use the code without Ctrl + C or Ctrl + V. Instead, call the corresponding method directly
Doing so can also shorten the original method and make it more concise and understandable
What’s more, if the code needs to be changed, it needs to be changed in only one place, rather than all over the place
That’s three birds with one arrow
IDEA is used to extract redundant code
-
Finding duplicate code
-
Right-click -> Select Refactor -> Extract -> Method (or just use the shortcut Ctrl + Alt + M)
IDEA automatically detects subtle differences in individual duplicate code that may Change only one or two variables and reminds us when extracting methods. Selecting Accept Signature Change on the left enables extracting methods to automatically replace more duplicate points
Option to replace all duplicate code (18)
-
Refactoring – Changes the method signature
If you are not satisfied with the extracted method name, parameter, return value or modifier, do not use Ctrl + R to change it. IDEA provides a refactoring method — change the signature (shortcut Ctrl + F6).
Note: The name of the method refers to what the method does, not how it does it
Tom. Sweep the floor () √
Tom. Sweep the floor With the broom
Tom. Sweep the floor with a broom () ×
Refactoring – Transfer member variables + functions (transfer responsibilities)
Transfer out member variables and functions that should not be managed by you
There are two questions to consider: who to move? To whom?
Let’s look at a picture
- The member [partial A] in the figure is called twice by class [A], but only once by its own class [long class], so it should be transferred to [A] to manage
- Since function [partial A] has A high degree of intimacy with member [partial A] (only called [partial A]), it should advance and retreat together with [partial A], go or stay together, and transfer to [A].
- The same is true for members and functions
- Responsibility 1 (function [1] and member [partial responsibility 1]) and Responsibility 2 (function [2] and member [partial responsibility 2]) should extract a new class because no suitable class is found to be transferable
Notice that you decide which member variable to move first, and then which function to move
Migrate member variables and functions using IDEA
-
To Move a member variable, mouse select the member variable -> right-click ->Refactor->Move, and then select which class to Move to
-
Move function (same steps as move member variable)
Refactoring — Extract classes
When you find that the member variables and functions you want to transfer can’t find a suitable class, remember that this is the program world, and we programmers are the creators of classes and objects. It’s time to create a new class that takes over the responsibilities (member variables and functions) for us
Extract classes using IDEA
-
Refactor select the variables and functions you want to move, right-click Refactor, Extract, and Delegate to manage the variables and functions. Paramater Object or Method Object can be pulled out.)
Extracting parameter objects is not recommended, because parameter objects are usually used for methods with many parameters (replacing a long list of parameters with parameter objects), and if the extraction of member variables does not affect any function, it is useless, so it is better to delete them
-
Give the new class a name and choose a package
-
Note that the extracted functions and members must conform to a principle, that is, the extracted function must use the extracted members more times than the remaining functions, otherwise it violates the intimacy principle (members should belong to the class that calls them the most, there is no reason for you to use more than me and let me manage).
-
A few minor problems
A refactoring failure due to an extracted function directly using an unextracted object, involving another refactoring (using the GET method instead of using private member variables directly), can be resolved using this refactoring
Welcome to the blog of Orange Fungus. This article is published by OpenWrite!