Move Method Refactoring

• Move Method refactoring is defined as relocating a method from its current host class to a target class to improve cohesion and modularity.
• The process involves a multi-step lifecycle that includes candidate selection, semantic analysis using embeddings, and IDE precondition validation.
• Empirical evaluations show that integrating LLM guidance with static analysis dramatically reduces invalid suggestions while enhancing runtime efficiency.

Searching arXiv for papers on Move Method refactoring and closely related automated refactoring work. Move Method refactoring is a software refactoring that relocates a method $m$ from its current host class $H$ to a more appropriate target class $T$, and can be formalized as the triplet $\omega=(m,H,T)$ (Batole et al., 26 Mar 2025). In the cited treatment, the operation is motivated by the need to improve modularity, cohesion, and coupling by aligning behavior with the data and responsibility it actually uses, and it is presented as closely tied to removing smells such as Feature Envy, God Class, Duplicated Code, and Message Chain (Batole et al., 26 Mar 2025). The same source characterizes Move Method as one of the most common refactorings in practice and argues that its lifecycle is inherently multi-step, requiring both global reasoning and safe execution rather than isolated recommendation alone (Batole et al., 26 Mar 2025).

1. Definition and conceptual scope

Move Method refactoring is defined as “a refactoring that moves method $m$ from host class $H$ to target class $T$,” with the basic formal object represented as $(m,H,T)$ (Batole et al., 26 Mar 2025). A recommendation system for this task returns a ranked list of recommendations, denoted by $\Re$, and a recommendation is considered valid when it is mechanically feasible and passes IDE preconditions (Batole et al., 26 Mar 2025). In this formulation, the core problem is not merely to identify a misplaced method, but to determine both whether relocation is warranted and which destination class is appropriate.

The cited work places Move Method within a broader design-maintenance context. The refactoring is presented as improving modularity, cohesion, and coupling by bringing behavior into closer correspondence with the class that owns the relevant data or responsibility (Batole et al., 26 Mar 2025). This suggests that the task has both semantic and structural dimensions: semantic, because the “fit” between a method and a class concerns purpose and dependency alignment; structural, because the move must remain valid under language and tool constraints.

A further implication of the formalization is that the method component and the target-class component can be evaluated separately. The paper therefore distinguishes between recovering the correct method, recovering the correct class given the method, and recovering the exact method-target pair (Batole et al., 26 Mar 2025). This decomposition is central to how contemporary automated systems measure success.

2. Refactoring lifecycle and end-to-end automation

The modern automated treatment described in the source does not treat Move Method as a single prediction problem. Instead, it presents an end-to-end lifecycle consisting of five stages: identifying candidate methods, finding candidate target classes, filtering invalid or hallucinated suggestions using static analysis and IDE preconditions, ranking the remaining recommendations with LLM guidance, and executing the refactoring safely using the IDE’s refactoring APIs after user approval (Batole et al., 26 Mar 2025).

This lifecycle is embodied in M$^2$aide (“Move Method Professional”), an IntelliJ IDEA plugin for Java described as the first end-to-end LLM-powered assistant for Move Method (Batole et al., 26 Mar 2025). The system is framed as a synergy among LLMs for semantic reasoning and prioritization, IDE and static analysis for mechanical correctness and precondition checking, semantic embeddings for method and class relevance, and refactoring-aware retrieval-augment generation (RAG) for overcoming context-window limits in project-wide target-class search (Batole et al., 26 Mar 2025). The important conceptual point is that recommendation, validation, and execution are treated as a unified workflow.

The paper’s account of execution is especially notable because it preserves the distinction between suggestion quality and refactoring safety. Once a recommendation is selected by the user, the system packages it into a refactoring command and invokes the IDE’s automated refactoring APIs to move the method, update call sites, and adjust references or accesses while preserving correctness through the IDE’s built-in mechanisms (Batole et al., 26 Mar 2025). This means the assistant does not merely propose a code edit; it delegates the transformation to a toolchain designed to enforce refactoring preconditions.

A plausible implication is that automated Move Method support becomes practically useful only when the full path from candidate generation to mechanically safe application is covered. The cited work explicitly argues that existing tools are incomplete precisely because the lifecycle is multi-step and demands both global reasoning and safe execution (Batole et al., 26 Mar 2025).

3. Candidate identification and target-class retrieval

Method identification in the cited system begins with sanity filtering. The paper removes methods that are obviously poor candidates for Move Method, specifically getters and setters, methods involved in inheritance chains where moving would require extra structural changes, test methods, and empty or comment-only methods (Batole et al., 26 Mar 2025). This screening stage narrows the search space before semantic analysis is applied.

After sanity filtering, the system uses code embeddings from VoyageAI to estimate semantic fit between the method and its host class (Batole et al., 26 Mar 2025). The method body and the host class body excluding the method are embedded, and the comparison is made via cosine similarity; lower similarity indicates a stronger candidate for moving (Batole et al., 26 Mar 2025). The LLM is then used with Chain-of-Thought reasoning to rank candidate methods by cohesion, purpose, and dependency alignment (Batole et al., 26 Mar 2025). The procedure therefore combines quantitative semantic resemblance with qualitative ranking.

Target-class retrieval depends on whether the method is instance or static. For instance methods, feasible destinations are restricted to types appearing in the host class’s fields and the method’s parameter types, after which IDE preconditions retain only mechanically valid targets (Batole et al., 26 Mar 2025). For static methods, the search space is broader, and the paper uses heuristics based on package proximity and utility-class identification. The ranking function is given as

$H$0

where $H$1 measures shared package structure normalized by host-package depth, and $H$2 is 1 if the class looks like a utility class and 0 otherwise (Batole et al., 26 Mar 2025).

Semantic relevance is again computed using VoyageAI embeddings, and target classes are sorted by cosine similarity (Batole et al., 26 Mar 2025). The retrieved context is limited to fit within a 7K token budget, typically around 10–12 class summaries, after which the LLM receives the method and the summarized candidate target classes and chooses the best one (Batole et al., 26 Mar 2025). This design reflects the paper’s claim that Move Method requires global, project-level reasoning, but that such reasoning must be controlled by retrieval and summarization to remain computationally tractable.

4. Hallucinations, validity, and ranking

A central issue in LLM-assisted Move Method refactoring is hallucination. The paper reports three hallucination types: H1, target class does not exist; H2, mechanically infeasible move; and H3, invalid methods that require additional refactorings to be valid, such as moving a getter or setter without its field (Batole et al., 26 Mar 2025). This typology frames the main reliability problem for raw LLM recommendations.

The reported empirical results indicate that hallucinations dominate vanilla GPT-4o suggestions. On the synthetic corpus with 235 gold refactorings, the paper reports 723 total suggestions, including 362 H1, 168 H2, and 51 H3, with only 142 of 723 valid (Batole et al., 26 Mar 2025). On the real-world corpus with 210 gold refactorings, it reports 1,293 total suggestions, including 431 H1, 275 H2, and 320 H3, with only 267 of 1,293 valid (Batole et al., 26 Mar 2025). The paper states that only about 20% of vanilla LLM recommendations are valid, meaning around 80% are hallucinations (Batole et al., 26 Mar 2025).

The proposed mitigation is a staged filtering workflow: generate candidates with the LLM, check candidate methods against refactoring sanity rules, use IDE and static-analysis preconditions to eliminate infeasible method-target pairs, use embeddings and RAG to narrow to semantically relevant classes, ask the LLM to self-rank the reduced set, and return only a short list of high-quality recommendations (Batole et al., 26 Mar 2025). The paper explicitly characterizes this as combining the “creative” role of the LLM with the “scientific” role of static analysis, and it claims that IDE preconditions plus semantic filtering can remove all hallucinations in the workflow used by M$H$3aide (Batole et al., 26 Mar 2025).

This treatment also corrects a common misconception that high-quality natural-language or code reasoning is sufficient for safe refactoring. The cited evidence indicates the opposite: raw LLM outputs can be semantically plausible yet mechanically invalid at very high rates (Batole et al., 26 Mar 2025). The paper’s broader implication is that LLMs are useful for refactoring only when paired with strong validation and context control.

5. Formal evaluation framework and empirical results

The paper uses recall-based metrics rather than precision, arguing that recall is more appropriate for ranking a small number of actionable recommendations (Batole et al., 26 Mar 2025). It defines

$H$4

where $H$5 is the gold set of true Move Method refactorings, $H$6 is the subset of recommendations whose method component matches the gold set, and $H$7 are exact method-target matches (Batole et al., 26 Mar 2025). Results are reported as Recall@$H$8 for $H$9 (Batole et al., 26 Mar 2025).

The experimental setup is multi-methodology, consisting of a formative study, comparative study, replication of real-world refactorings, repository mining, runtime evaluation, and a user study with experienced developers (Batole et al., 26 Mar 2025). Two datasets are used. The synthetic corpus is the widely used benchmark from Terra et al., with 10 open-source projects and 235 refactorings in the instance-method benchmark, constructed by moving methods and then using the original location as oracle (Batole et al., 26 Mar 2025). The real-world corpus is mined from 25 actively maintained Java repositories on GitHub using commits from January 2024 onward, yielding a final oracle of 210 verified Move Method refactorings, including 102 static methods and 108 instance methods, with average project size reported as 8,743 classes, 66,306 methods, and 1,032,344 LOC (Batole et al., 26 Mar 2025).

The main baselines are JMove, feTruth, HMove, and Vanilla GPT-4o (Batole et al., 26 Mar 2025). On the 235-instance-method synthetic benchmark, M$T$0aide achieves $T$1 and $T$2, compared with JMove’s 40% and 42%, described as about a 1.7× improvement (Batole et al., 26 Mar 2025). More detailed synthetic results reported for M$T$3aide are $T$4, $T$5, $T$6, $T$7, $T$8, and $T$9 (Batole et al., 26 Mar 2025). Vanilla GPT-4o is described as competitive on method identification but weaker on exact pair matching, with $\omega=(m,H,T)$0 (Batole et al., 26 Mar 2025).

On the real-world corpus, performance varies substantially by method type and class size. For 108 real-world instance-method refactorings in small classes, M$\omega=(m,H,T)$1aide achieves $\omega=(m,H,T)$2 and $\omega=(m,H,T)$3, with a claimed improvement of 2.4× to 4× over baselines on $\omega=(m,H,T)$4 (Batole et al., 26 Mar 2025). For large classes, performance drops to $\omega=(m,H,T)$5 and $\omega=(m,H,T)$6, though it still outperforms the baselines (Batole et al., 26 Mar 2025). For the 102 static methods, the task is described as much harder: $\omega=(m,H,T)$7 for small classes and 15% for large classes (Batole et al., 26 Mar 2025).

6. Runtime, usability, and practical constraints

The paper reports that M$\omega=(m,H,T)$8aide runs in about 27.5 seconds on average to generate suggestions, with roughly 9 seconds attributable to LLM API time (Batole et al., 26 Mar 2025). It is reported as two orders of magnitude faster than JMove, two orders of magnitude faster than HMove, and one order of magnitude faster than feTruth (Batole et al., 26 Mar 2025). By contrast, JMove is said often to require hours on large projects, HMove around 80 minutes on average per entry and up to 4 days in extreme cases, and feTruth around 6 minutes per class with author help or otherwise 12+ hours on large projects (Batole et al., 26 Mar 2025).

The difficulty of static-method refactoring is traced to the size of the destination space. The paper notes that for a single static method in Elasticsearch, the search space can be approximately 21,615 target classes, leading to about 14 days of processing in the HMove-style setup (Batole et al., 26 Mar 2025). This is presented as an explanation for why static-method Move Method remains substantially harder than the instance-method case.

The user study adds an adoption-oriented perspective. Thirty participants—25 master’s students and 5 PhD students, most with Java and refactoring experience—used M$\omega=(m,H,T)$9aide on their own code for a week (Batole et al., 26 Mar 2025). They ran it on 350 classes, accepted and applied 216 recommendations total, and positively rated recommendations in 290 classes, reported as 82.8%; the paper also states that 80% rated the plugin experience highly relative to IDE workflow (Batole et al., 26 Mar 2025). The reported conclusion is that developers found the tool useful, controllable, and aligned with their own judgment (Batole et al., 26 Mar 2025).

A plausible implication is that practical success depends not only on ranking accuracy but also on latency, user control, and integration with familiar IDE workflows. The source repeatedly emphasizes safe execution after user approval rather than autonomous application (Batole et al., 26 Mar 2025).

7. Limitations, scope, and broader significance

The cited work acknowledges several limitations. Results are tied to GPT-4o, although the approach is presented as model-agnostic (Batole et al., 26 Mar 2025). The implementation scope is currently Java, and extension to other languages or refactorings would require new static analysis for preconditions, semantic-analysis adaptations, and execution mechanics for the target ecosystem (Batole et al., 26 Mar 2025). The paper also notes dataset bias as a potential threat to validity, mitigated by using both a standard synthetic benchmark and a mined real-world benchmark, and it remarks on the non-deterministic nature of LLMs while reporting low variance under temperature variation in the experiments (Batole et al., 26 Mar 2025).

The broader significance assigned to Move Method in this account is methodological. Prior refactoring tools are said often to optimize metrics but not align well with expert developer judgment, whereas the goal of M$m$0aide is to better match real-world refactoring decisions while remaining fast enough for everyday use (Batole et al., 26 Mar 2025). This positions Move Method not merely as a local transformation rule, but as a refactoring task that requires project-level semantic reasoning, precondition-aware validation, and integration into a usable software-engineering workflow.

The paper’s main implication for refactoring practice is explicit: LLMs are useful for refactoring only when paired with strong validation and context control (Batole et al., 26 Mar 2025). By itself, an LLM can generate many plausible but invalid Move Method suggestions; when combined with semantic embeddings to detect misfit methods, IDE and static analysis to enforce feasibility, RAG to constrain the target-class search space, and LLM ranking to select the best recommendation among valid candidates, the full Move Method lifecycle can be automated end to end (Batole et al., 26 Mar 2025). This suggests that the contemporary understanding of Move Method is increasingly shaped by hybrid systems in which semantic inference and mechanical correctness are treated as complementary rather than competing capabilities.