## 4 Design
### Dataset
#### 4.1.2 Features Related to Move Method Refactoring  
In the exploration of MMR, a key challenge is identifying the key features that are most likely to be affected by refactoring operations. After careful evaluation, the feature set identified included two critical dimensions: metric-based features and semantic-based features. To accurately identify metrics, we analyzed project versions before and after the refactoring process, aiming to identify metrics that exhibited changes. However, it is important to note that not all observed changes can be solely attributed to refactoring, as some may stem from alterations in the underlying code logic. Through analyzing the source code before and after refactoring, complemented by domain expertise, we identified 31 metric-based features influenced by MMR. The selected metrics are presented in Table 2, including 23 class-level metrics and 8 method-level metrics, where T indicates whether the metric is a class- or method-level metric. The selection of these metrics was based on three primary considerations. Firstly, they had to remain numerical regardless of the target class's location, so that the model could effectively learn and predict. Secondly, their values changed before and after the refactoring, and these changes were due to the refactoring operation and not other code logic changes. Thirdly, the selected metrics had to have a certain correlation with the program performance and affect the execution time of the program. The reasons for each metric's selection are presented in Table 3. Here, CBO, CBO Modified, FAN-IN, FAN-OUT, and RFC contain both class and method levels. CBO Modified is very similar to CBO; however, this metric considers the dependency of a class in terms of both the references that it makes to others and the references that it receives from other types. The metric LCOM* represents a standardized version of LCOM, with values ranging between 0 and 1. Both metrics are retained because LCOM* is not simply a scaled form of LCOM. Instead, it incorporates the concept of a connected graph to provide a more accurate and consistent assessment of the cohesion among methods within a class. Additionally, due to the different calculation methods employed by the two metrics, they may exhibit distinct relationships with other features and exert varying influences on the model. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Metric** & **Class** & **Method** & **Description** \\ \hline CBO & T & T & Coupling between objects \\ CBO Modified & T & T & Coupling between objects \\ FAN-IN & T & T & Input dependencies \\ FAN-OUT & T & T & Output dependencies \\ WMC & T & & Weight method class \\ RFC & T & T & Response for a class \\ DIT & T & & Depth inheritance trees \\ NOC & T & & Number of children \\ LOC & T & & Lines of code \\ NOSI & T & & Number of static invocations \\ LCOM & T & & Lack of cohesion of methods \\ LCOM* & T & & Lack of cohesion of methods \\ modifiers & T & Public/abstract/private/protected/native \\ totalMethodsQty & T & & Total number of methods \\ publicMethodsQty & T & & Number of public methods \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Selected metrics. In addition to these metrics, we further integrate the consideration of semantic information to achieve a more nuanced understanding of the target class's attributes. Within the target class, we observe that the proposed method is able to predict the correct semantic information to be retrieved from the target class's attributes.