Identification of Move Method Refactoring Opportunities 阅读笔记

1. 文章结构

Section 1 is an introduction. Section 2 provides an overview of the related work. The proposed methodology is thoroughly analyzed in Section 3, and Section 4 presents the tool that implements it. The results of the evaluation are discussed in Section 5. Finally, we conclude in Section 6.

2. 部分原文及翻译

1 INTRODUCTION

According to several principles and laws of object oriented design [18], [25], designers should always strive for low coupling and high cohesion. A number of empirical studies have investigated the relation of coupling and cohesion metrics with external quality indicators. Basili et al. [3] and Briand et al. [7] have shown that coupling metrics can serve as predictors of fault-prone classes. Briand et al. [8] and Chaumun et al. [12] have shown high positive correlation between the impact of changes (ripple effects, changeability) and coupling metrics. Brito e Abreu and Melo [11] have shown that Coupling Factor [10] has very high positive correlation with defect density and rework. Binkley and Schach [4] have shown that modules with low coupling (as measured by Coupling Dependency Metric) require less maintenance effort and have fewer maintenance faults and fewer runtime failures. Chidamber et al. [14] have shown that high levels of coupling and lack of cohesion are associated with lower productivity, greater rework, and greater design effort. Consequently, low coupling and high cohesion can be regarded as indicators of good design quality in terms of maintenance.
根据面向对象设计[18]、[25]的几个原则和规律，设计师应始终追求低耦合和高内聚。许多实证研究已经调查了耦合和内聚指标与外部质量指标的关系。Basili等人[3]和Briand等人[7]已经证明，耦合指标可以作为故障易发的类的预测器。Briand等人[8]和Chaumun等人[12]揭示了变化的影响（涟漪效应、可变性）和耦合指标之间的高度正相关。Brito e Abreu和Melo [11]的研究表明，耦合因子[10]与缺陷密度和返工有非常高的正相关关系。Binkley和Schach [4]的研究表明，具有低耦合（通过耦合依赖度指标来测量）的模块需要更少的维护工作，并且有更少的维护故障和更少的运行时故障。Chidamber等人。[14]的研究表明，高水平的耦合和缺乏内聚力与较低的生产率、更多的返工和更大的设计工作量有关。因此，从维护的角度出发，低耦合和高内聚可以作为良好设计质量的指标。
Coupling or cohesion problems manifest themselves in many different ways, with Feature Envy bad smell being the most common symptom. Feature Envy is a sign of violating the principle of grouping behavior with related data and occurs when a method is “more interested in a class other than the one it actually is in” [17]. Feature Envy problems can be solved in three ways [17]: 1) by moving a method to the class that it envies (Move Method refactoring); 2) by extracting a method fragment and then moving it to the class that it envies (Extract þ Move Method refactoring); and 3) by moving an attribute to the class that envies it (Move Field refactoring). The correct application of the appropriate refactorings in a given system improves its design quality without altering its external behavior. However, the identification of methods, method fragments, or attributes that have to be moved to target classes is not always trivial since existing metrics may highlight coupling/cohesion problems but do not suggest specific refactoring opportunities.
耦合或内聚问题表现在许多不同的方式，其中特征嫉妒的坏味道是最常见的症状。特征嫉妒是违反相关数据分组行为原则的标志，当一个方法“对其他类比其真正所属的类更感兴趣”时，就会发生这种情况。特征嫉妒问题可以通过三种方式解决[17]： 1)将方法移动到它羡慕的类（移动方法重构）；2)提取方法片段，然后将其移动到它羡慕的类（提取+移动方法重构）；3)将属性移动到羡慕它的类（移动字段重构）。在给定的系统中正确地应用适当的重构可以在不改变其外部行为的情况下提高其设计质量。然而，识别必须移动到目标类的方法、方法片段或属性并不简单，因为现有的度量方式可能会突出耦合/内聚问题，但不会给出具体的重构机会。
Our methodology considers only Move Method refactorings as solutions to the Feature Envy design problem. Moving attributes (fields) from one class to another has not been considered, since this strategy would lead to contradicting refactoring suggestions with respect to the strategy of moving methods. Moreover, fields have stronger conceptual binding to the classes in which they are initially placed since they are less likely than methods to change once assigned to a class.
我们的方法只考虑移动方法重构作为特征嫉妒设计问题的解决方案。没有考虑将属性（字段）从一个类移动到另一个类，因为这种策略会导致关于移动方法策略的矛盾重构建议。此外，字段对它们最初被放置的类具有更强的概念绑定，因为比起方法来说，字段在分配给类之后更不可能进行更改。
In this paper, the notion of distance between an entity (attribute or method) and a class is employed to support the automated identification of Feature Envy bad smells. To this end, an algorithm has been developed that extracts Move Method refactoring suggestions. For each method of the system, the algorithm forms a set of candidate target classes where the method can possibly be moved by examining the entities that it accesses from the system classes (system classes refer to the application or program under consideration excluding imported libraries or frameworks). Then, it iterates over the candidate target classes according to the number of accessed entities and the distance of the method from each candidate class. Eventually, it selects as the final target class the first one that satisfies a certain list of preconditions related with the application of Move Method refactorings. The examination of preconditions guarantees that the extracted refactoring suggestions are applicable and preserve the behavior of the code.
本文利用实体（属性或方法）与类之间的距离概念来支持特征嫉妒这一坏味道的自动识别。为此，提出了一种提取移动方法重构建议的算法。对于系统的每一种方法，算法都形成一组候选目标类，这是通过检查其从系统类访问的实体来做到的（系统类指当前研究的应用或程序，不包括导入的库或框架）。然后，根据待移动方法访问实体的数量，以及其与每个候选类之间的距离，对候选目标类进行迭代。最终，它选择满足与移动方法重构应用相关的一定先决条件的列表中的首个目标类作为最终的目标类。对前提条件的检查保证了所提取的重构建议是适用的，并保留了原本代码的行为。
Obviously, in large applications, several refactoring suggestions may be extracted hindering the designer to assess the effect of each refactoring opportunity. To this end, an Entity Placement metric is proposed to rank the refactoring suggestions according to their effect on the design. This metric is based on two principles: 1) The distances of the entities belonging to a class from the class itself should be the smallest possible (high cohesion) and 2) the distances of the entities not belonging to a class from that class should be as large as possible (low coupling).
显然，在大型应用程序中，可能只有一部分重构建议会被提出，从而阻碍了设计者评估每个重构机会所带来的的影响。为此，本文提出了一种实体放置度量方法，根据重构建议对设计的影响，对其进行排序。这个度量基于两个原则： 1)属于一个类的实体与类本身的距离应该是最小的（高内聚性），2)不属于一个类的实体与该类的距离应该尽可能大（低耦合）。
The actual application of the refactoring suggestions on source code in order to calculate the Entity Placement metric value that the resulting systems will have can be very time-consuming, especially when the number of suggestions is large. The proposed methodology offers the advantage of evaluating the effect of a Move Method refactoring without actually applying it on source code. This is achieved by virtually moving methods and calculating the Entity Placement metric.
实际应用中，计算源代码的重构建议的实体放置度量值可能非常耗时，特别是在建议数量很大的情况下。本文所提出的方法在评估移动方法重构之效果时，不必将重构实际应用于源代码。这是本文提出的算法的优点之一，是通过虚拟移动的方法和计算实体放置度量来实现的。
It should be emphasized that the proposed methodology is by no means a fully automatic approach. In other words, after the extraction of the refactoring suggestions, the designer is responsible for deciding whether a refactoring should be applied or not based on conceptual or other design quality criteria. For example, cases that require the designer’s knowledge on the examined system are User Interface methods that should not be moved to classes holding data due to the Model-View-Controller pattern, test methods that should be not moved to the classes being tested (such cases are discussed in Section 5.1), and methods of a composing class that should not be moved to its contained classes due to composition relationships. The tool implementing the proposed methodology assists the designer in determining the reason behind selecting a specific target class over other possible target classes.
应当强调的是，所拟议的方法绝不是一种全自动的方法。换句话说，在提取出重构建议后，设计者负责根据概念性或其他设计质量标准来决定是否应该应用重构。例如，由于模型-视图-控制器模式的要求，User接口方法不应移动到保存数据的类；测试方法不应该移动到被测试的类（此类情况在第5.1节中讨论）；以及由于组合关系，组合类的方法不应移动到其包含类。实现了本文所提出的推荐方法的工具，可以帮助设计师明确为什么要选择一个特定的目标类而不是其他可能的目标类。
The evaluation of the proposed methodology consists of four parts. The first part contains a qualitative analysis of the refactoring suggestions extracted for an open-source project, along with some interesting insights obtained from the inspection and application of the suggestions. The second part studies the evolution of coupling and cohesion metrics when successively applying the refactoring suggestions extracted for two open-source projects. In the third part of the evaluation, an independent designer provides feedback concerning the conceptual integrity of the refactoring suggestions extracted for the system that he developed. The last part refers to the efficiency of the methodology based on the computation time required for the extraction of refactoring suggestions on various opensource projects.
对函数移动重构推荐方法的评价包括四个部分。第一部分定性分析了该方法对一个开源项目的重构建议，也包含从这些建议的检查和应用中获得的一些有趣见解。第二部分研究了在先后应用推荐方法为两个开源项目提取的重构建议时，耦合性和内聚性度量的演变。在评估的第三部分中，一个独立的设计师反馈了推荐方法为他开发的系统提取的重构建议的概念完整性。最后一部分基于提取各种开源项目的重构建议所需的计算时间，讨论了推荐方法的效率。
The rest of the paper is organized as follows: Section 2 provides an overview of the related work. The proposed methodology is thoroughly analyzed in Section 3, and Section 4 presents the tool that implements it. The results of the evaluation are discussed in Section 5. Finally, we conclude in Section 6.
本文的其余部分组织如下：第2节提供了有关工作的概述。第3节对本文提出的方法进行了彻底的分析，第4节介绍了实现此方法的工具。评估的结果将在第5节中进行讨论。最后，我们在第6节中进行总结。

2 RELATED WORK

According to Mens and Tourwe[26], the refactoring process consists of the following distinct activities:
根据Mens和Tourwe[26]的理论，重构过程包括以下不同的活动：

1.Identify places where software should be refactored (known as bad smells) and determine which refactoring(s) should be applied.
2.Guarantee that the applied refactoring preserves behavior.
3.Apply the refactoring.
4.Assess the effect of the refactoring on quality characteristics of the software.
5.Maintain the consistency between the refactored code and other software artifacts (such as documentation, design documents, tests, etc.).
1.确定软件应该被重构的地方（称为不良气味），并确定应该应用哪种重构。
2.保证所应用的重构能够保留原有行为。
3.应用重构。
4.评估重构对软件质量特性的影响。
5.维护重构代码与其他软件工件（如文档、设计文档、测试等）之间的一致性。

The proposed methodology covers activities 1-4 concerning Move Method refactorings.
本文提出的方法包括移动方法重构的第1-4步。
Simon et al. [32] define a distance-based cohesion metric, which measures the cohesion between attributes and methods. This metric aims at identifying methods that use or are used by more features of another class than the class that they belong to, and attributes that are used by more methods of another class than the class that they belong to. The calculated distances are visualized in a three-dimensional perspective supporting the developer to manually identify refactoring opportunities. However, visual interpretation of distance in large systems can be a difficult and subjective task. The approach does not evaluate the effect of each refactoring on the architecture of the resulting system inhibiting the selection of those refactorings that will actually improve the design. Moreover, the case studies used for demonstrating their approach are small systems written by the authors with very obvious bad smells.
Simon等人[32]定义了一个基于距离的内聚力度量，它度量属性和方法之间的内聚力。这个度量的目的是识别相较于其所在的类，更多地使用或更多地被另一个类的成员使用的方法，以及相较于其所在的类，更多地被另一个类的方法使用的属性。计算出的距离以三维视角可视化，以支持开发人员手动识别重构机会。然而，在大型系统中，对距离的视觉解释可能是一项困难和主观的任务。该方法没有评估每个重构对系统体系结构的影响，没有突出展现那些真正改进设计的重构的选择。此外，用于展示他们方法的案例中，进行重构的是由作者编写的具有非常明显的坏气味的小型系统。
Our approach is inspired by the work of Simon et al. in the sense that it also employs the Jaccard distance. However, the difference is that our approach defines the distance between an entity (attribute or method) and a class enabling the direct extraction of refactoring suggestions, while the approach of Simon et al. defines the distance between two entities and, thus, its
output requires the application of clustering techniques or visual interpretation in order to extract Move refactoring suggestions to specific classes. To summarize, our methodology exhibits the following advantages:
我们的方法受到Simon等人工作的启发，因为它也使用了Jaccard距离。然而，不同之处在于，我们的方法定义了一个实体（属性或方法）和一个类之间的距离，使得该方法指导提取重构建议成为可能；而Simon等人的方法定义了两个实体之间的距离，因此，其输出需要应用聚类技术或视觉解释以提取将到特定的类的移动重构建议。综上所述，我们的方法具有以下优点：

1.It clearly indicates which methods and to which class they should be moved.
2.It suggests refactorings which are applicable and behavior-preserving by examining a list of preconditions.
3.It efficiently ranks multiple Move Method refactoring suggestions based on their positive influence on the design of the system.
4.It has been evaluated on large-scale open-source projects.
5. It has been fully automated and implemented as an Eclipse plug-in, allowing the developer to apply the suggested refactorings on the source code.
1.它清楚地指示哪些方法应当被移动，以及它们应当被移动到哪个类。
2.它通过检查一系列前提条件来推荐合适的且保留之前行为的重构。
3.基于多个移动方法重构建议对系统设计的积极影响，有效地对多个移动方法重构建议进行了排序。
4.它已经在大型开源项目中进行了评估。
5.它是完全自动化的，并被实现为一个Eclipse插件。功能为允许开发者对源代码实施推荐的重构。

Tahvildari and Kontogiannis [33] use an object-oriented metrics suite consisting of complexity, coupling, and cohesion metrics to detect classes for which quality has deteriorated and re-engineer detected design flaws. In particular, they identify possible violations of design heuristics by assessing which classes of the system exhibit problematic metric values, and then select an appropriate metapattern that will potentially improve the corresponding metric values. A limitation of their approach is that it
indicates the kind of the required transformation but does not specify on which specific methods, attributes, or classes this transformation should be applied (this process requires human interpretation). Moreover, in case of multiple potential suggestions, the approach does not evaluate their effect in order to rank them.
Tahvildari和Kontogiannis[33]使用一个面向对象的指标套件，包括复杂性、耦合和凝聚力指标，来检测质量恶化的类并对检测到的设计缺陷进行返工。特别是，它们通过评估系统的哪些类显示出有问题的度量值来识别可能违反设计原则的行为，然后选择一个适当的元模式，以求改进相应的度量值。他们的方法的一个局限性是，它指示了所需转换的类型，但没有指定该转换应该应用于哪些特定的方法、属性或类（这个过程需要人工解释）。此外，在有多个潜在建议的情况下，该方法不评估它们的效果，因此也就不会对它们进行排序。
O’Keeffe and O’Cinneide [22] treat object-oriented design as a search problem in the space of alternative designs. For this purpose, they employ search algorithms, such as Hill Climbing and Simulated Annealing, using metrics from the QMOOD hierarchical design quality model [2] as a quality evaluation function that ranks the alternative designs. The refactorings used by the search algorithms to move through the space of alternative designs are only inheritance-related (Push Down Field/Method, Pull Up Field/Method, and Extract/Collapse Hierarchy).
O’Keeffe和O’Cinneide[22]将面向对象设计视为替代设计空间中的一个搜索问题。因此，他们使用了搜索算法，如爬山和模拟退火，使用来自QMOOD层次设计质量模型[2]的指标作为质量评估函数，对替代设计进行排名。搜索算法在替代设计空间中选用的重构方案仅与继承相关（如Push Down Field/Method, Pull Up Field/Method, and Extract/Collapse Hierarchy）。
Seng et al. [31] use a special model that examines a set of pre and postconditions in order to simulate the application of Move Method refactorings and a genetic algorithm to propose Move Method refactoring suggestions that improve the class structure of a system based on a fitness function. Their approach also includes an initial classification process which excludes from optimization, methods playing special roles in the system’s design, such as getter and setter methods, collection accessors, delegation methods, state methods, factory methods, and methods participating in design patterns. The methodology proposed by Seng et al. has the following differences compared to our methodology:
Seng等人[31]使用一种特殊的模型，检查一组前条件和后条件来模拟移动方法重构的应用，并使用遗传算法提出移动方法重构建议，基于适应度函数改进系统的类结构。他们的方法还包括一个能通过一定优化来排除在系统设计中扮演特殊角色的方法的初始分类过程，如getter and setter methods, collection accessors, delegation methods, state methods, factory methods和参与设计模式的方法。Seng等人提出的方法与我们的方法有以下不同之处：

1.It produces as output a sequence of refactorings that should be applied in order to reach an optimal system in terms of the employed fitness function. If the designer decides not to apply some of the suggested refactorings, then the resulting system might be worse than a system resulting from other sequences that have not been presented as solutions to the designer. Moreover, the application of the refactoring suggestions might lead to new refactoring opportunities (not originally present in the initial system), which are not taken into account in the proposed solution. On the contrary, a stepwise approach in which, after the application of each refactoring, the system is reevaluated and a new list of refactorings that improve the current system is extracted (including any new refactoring opportunities that might have arisen), provides the possibility to the designer to assess the conceptual integrity of the suggestions at each step. Consequently, the designer is able to determine a sequence of refactoring applications that are conceptually sound and at the same time optimize certain software metrics.
1.它产生一系列的重构，应该应用，以达到所使用的适应度函数的最优系统。如果设计者决定不应用一些建议的重构，那么产生的系统可能比没有作为设计者解决方案的其他序列产生的系统更糟糕。此外，重构建议的应用可能会导致新的重构机会（最初在初始系统中没有出现），而在提议的解决方案中没有考虑到这些机会。相反，循序渐进的方法，应用每个重构后，系统重新评估和一个新的重构列表，改进当前系统提取（包括任何新的重构机会可能出现），提供了可能性，设计师评估的概念完整性建议在每一步。因此，设计者能够确定一系列概念上可靠的重构应用程序，同时优化某些软件度量。
2.It employs genetic algorithms that make random choices on mutation and crossover operations and, as a result, the outcome of each execution on the same input system may differ. Moreover, the outcome depends on initial parameter settings decided by the user. On the contrary, a deterministic approach which suggests refactorings based on Feature Envy criteria always results in the same solution for a certain system.
2.它采用了遗传算法，在突变和交叉操作上做出随机选择，因此，在同一输入系统上每次执行的结果可能会有所不同。此外，结果取决于由用户决定的初始参数设置。相反，基于特征嫉妒准则的确定性重构方法对某一系统总是能得到相同的解。
3.Its efficiency is limited by the following factors: a) It requires numerous generations in order to converge to a solution; b) the algorithm has to be executed several times (10 times in the example of the evaluation) in order to gather the common refactoring suggestions from all executions that will be reported as final results since each execution might lead to different results; and c) the algorithm includes in the optimization process all movable methods regardless of whether they suffer from Feature Envy problems or not.
3.它的效率受到以下因素的限制： a)它需要数次迭代才能收敛得到一个解；b)算法必须执行几次（在评估的例子中是10次），以便从所有执行中收集常见的重构建议，并报告为最终结果，因为每次执行可能导致不同的结果；c)算法在优化过程中会考虑所有可移动的方法，无论它们是否存在特征嫉妒问题。
4.It requires the definition of an arbitrary trapezoidal function for the normalization of certain metrics (such as WMC and NOM), a calibration run for optimizing each metric separately, and the specification of weights used in the definition of the employed fitness function. On the contrary, the Entity Placement metric does not rely on any arbitrary definition.
4.它需要定义一个任意的梯形函数来规范化某些度量（如WMC和NOM），需要进行校准运行以分别优化每个度量，也需要定义在其适应度函数定义中使用的权值规范。相反，实体放置度量并不依赖于任何定义。

Concerning the evaluation of refactoring effect on design quality, the following approaches appear in the literature.
关于重构对设计质量的评价，文献中有以下方法。
Kataoka et al. [21] propose a quantitative evaluation methodology to measure the maintainability enhancement effect of refactoring. They define three coupling metrics (return value, parameter, and shared variable coupling) in order to evaluate the refactoring effect. By comparing the metric values before and after the application of refactorings, they evaluate the degree of maintainability enhancement. The definition of each metric contains a coefficient that accounts for interclass coupling. The coefficient values are based on the specific characteristics of the system under study. However, the authors do not provide a systematic approach for estimating the coefficient values. Moreover, they did not include cohesion as a metric for evaluating the modification of maintainability caused by refactorings.
Kataoka等人[21]提出了一种定量评价方法来衡量重构的可维护性增强效果。它们定义了三个耦合度量（返回值、参数和共享变量耦合），以评估重构效果。通过比较重构应用前后的度量值，他们评估了可维护性增强的程度。每个度量的定义中都包含一个可以解释类间耦合的系数。系数值基于所研究的系统的具体特征。然而，作者并没有提供一个系统的方法来估计系数值。此外，它们没有将内聚力作为评估由重构造成的可维护性变化的指标。
Du Bois et al. [15] theoretically analyze the best and worst-case impact of refactorings on coupling and cohesion dimensions. The refactorings they studied are Extract Method, Move Method, Replace Method with Method Object, Replace Data Value with Object, and Extract Class. According to the authors, moving a method that does not refer to local attributes or methods, or is called upon by only few local methods will increase cohesion. Additionally, moving a method that calls external methods more frequently than it is called will decrease import coupling. These observations are in agreement with the principles on which our methodology is based.
Du Bois等人[15]从理论上分析了重构分解对耦合和内聚维度的最佳和最坏情况的影响。他们研究的重构方法有提取方法、移动方法、用方法对象替换方法、用对象替换数据值和提取类。根据作者的说法，移动一个不引用局部属性或方法的方法，或者只被少数局部方法所要求的方法将增加内聚力。此外，移动调用外部方法的频率大于其自身被调用的频率的方法将减少引用耦合。这些观察结果符合我们的方法所依据的原则。
The cumulative effect of move refactorings (in the sense that their application eventually leads to a system where behavior and data are grouped together properly) could also be theoretically achieved by clustering techniques. However, the object-oriented clustering techniques found in the literature [27], [24] refer to the partitioning and modularization of systems at class level rather than method level. Clustering techniques at method level could possibly lead to an optimal system in terms of coupling and cohesion. However, such techniques would present a solution that is an aggregate of multiple Move Method refactorings which
the designer should accept or reject in its entirety. A stepwise approach, on the other hand, might not lead to an optimal solution but offers the advantage of gradual change of a system, allowing the designer to assess the conceptual integrity of the refactoring suggestions at each step.
移动重构的累积效应（在它们的应用最终导致一个行为和数据正确分组的系统的意义上）在理论上也可以通过聚类技术来实现。然而，在文献[27]、[24]中发现的面向对象的聚类技术指的是在类级而不是方法级上的系统的划分和模块化。方法级的聚类技术可能在耦合和内聚方面的最优系统。然而，这样的技术将提出一个解决方案，它是多个移动方法重新分解的集合，设计者应该接受或拒绝其全部。另一方面，循序渐进的方法可能不会导致最优的解决方案，而是提供了对系统进行逐步更改的优势，允许设计者在每一步中评估重构建议的概念完整性。

3 METHODOLOGY

An object-oriented system is considered to be well-designed in terms of coupling and cohesion when its entities (attributes/methods) are grouped together according to their relevance. During analysis, relevance is usually evaluated on a conceptual basis. However, during design and implementation, relevance can be practically assessed considering the attributes and methods that a method accesses.
当面向对象系统中的实体（属性/方法）根据其相关性分组在一起时，该系统被认为在耦合和内聚方面是设计良好的。在分析过程中，相关性通常是基于概念而进行评估的。然而，在设计和实现过程中，可以通过一个方法所访问的属性和方法来实际评估其相关性。

The notation required for the rest of the methodology is graphically illustrated in the UML class diagram of Fig. 1. The model represents the types, properties, and relationships which are necessary in order to identify Feature Envy bad smells for a given Java program.
图1中展示了其他方法所需的符号。该模型展示了识别给定的Java程序中的特征嫉妒坏气味所必需的类型、属性和关系。
Within the context of the above model, a program has as property the ClassTypes that it contains (denoted as program.classTypes), excluding imported library or framework class types.
在上述模型的上下文中，程序具有其包含的类类型（表示为program.classTypes）作为属性，不包括导入的库或框架类类型。

3.1 Definition of Distance

A class in object-oriented programming consists of attributes and methods. Attributes may also be references to other classes of the system (i.e., attributes whose type is a system class), in order to provide access to the functionality of these classes. As a result, a method can access directly attributes and methods of the class that it belongs to and also attributes and methods of other classes through references. Likewise, an attribute can be accessed directly from methods of the class that it belongs to and also from methods of other classes that have a reference to that class.
面向对象编程中的一个类由属性和方法组成。属性也可以是对系统的其他类的引用（即，其类型是一个系统类的属性），以便提供对这些类的功能的访问。因此，一个方法可以通过引用直接访问其所属的类的属性和方法，也可以访问其他类的属性和方法。同样地，一个属性可以直接从它所属的类的方法访问，也可以从引用该类的其他类的方法访问。
For each entity (attribute/method), we define a set of the entities that it accesses (if it is a method) or the entities that it is accessed from (if it is an attribute).
对于每个实体（属性/方法），我们定义它访问的实体（如果该实体是方法）或访问它的实体（如果该实体是属性）为一个实体集。
The entity set of an attribute attr contains the following entities:
属性attr的实体集包含以下实体：
1 the methods directly accessing attr that belong to the same class with attr;
2 the methods accessing attr that belong to other classes of the system (accesses can be performed either through getter and setter invocations or in exceptional cases, directly when attr has public visibility).
1 与attr位于同一类下的方法直接访问attr；
2 位于系统其他类的方法访问attr（可以通过getter和setter访问，或者在特殊情况下，当attr具有public属性时直接执行访问）。

The entity set of a method m contains the following entities:
方法m的实体集包含以下实体：
1 the directly accessed attributes that belong to the same class with m;
2 the accessed attributes that belong to other classes of the system;
3 the directly accessed methods that belong to the same class with m;
4 the accessed methods through reference that belong to other classes of the system.
1 与m属于同一类的，可以直接访问的属性；
2 属于系统的其他类的可访问的属性；
3 与m属于同一类的，可以直接访问的方法；
4 通过对系统中的其他类的引用而可以被访问的方法。

Apart from the entity sets of methods and attributes, the entity set of a class C is also defined and contains the following entities:
除了方法和属性的实体集外，还定义了类C的实体集，其中包含以下实体：
1 all attributes that belong to class C;
2 all methods that belong to class C.
1 所有属于类C类的属性；
2 所有属于类C的方法。

For the formation of entity sets, the following rules should be taken into account. Rules are given in both a descriptive and a formal manner (auxiliary functions are defined in Appendix A).
关于如何生成实体集，应考虑以下规则。规则以描述性语言和数学语言两种方式给出（辅助函数在附录a中定义）。

1. Attributes that are references to classes of the system are not considered as entities nor added to the entity sets of other entities since such references are essentially a pipeline to the state or behavior of another class.
   系统中的类的引用不被视为实体，也不被添加到其他实体的实体集中，因为这些引用本质上是指向另一个类的状态或行为的管道。
   
2. Getter and setter methods are neither considered as entities nor added to the entity sets of methods and attributes, since they do not offer functionality except for access to attributes. However, the attributes to which they provide access are added to the entity sets. For an attribute that is a collection of objects, we consider as getters the methods that return an element at a specific position, or return an iterator/enumeration of the elements. As setters, we consider the methods that add an element to or replace an element of that collection.
   getter方法和setter方法既不被视为实体，也不被添加到方法和属性的实体集中，因为它们不提供除访问属性之外的功能。但是，由它们提供访问权限的属性会被添加到实体集中。对于一个本质上是对象集合的属性，当方法返回特定位置的元素或元素的迭代器/枚举类型时，我们将这个方法视为getter方法；作为设置器，我们将向该集合添加元素或替换元素的方法视为setter方法。
   
3. Static attributes and methods are neither considered as entities nor added to the entity sets of methods and attributes, since they can be accessed or invoked from any method without having any reference to the class that they belong to. An instance method requires the existence of a reference to a target class in order to be moved to that class, and as a result, it cannot be moved to a class from which it accesses only static members.
   静态属性和方法既不被视为实体，也不被添加到方法和属性的实体集中，因为可以从任何方法访问或调用它们，而无需对它们所属的类进行任何引用。实例方法需要存在对目标类的引用，才能移动到该类中，因此，不能将其移动到只访问静态成员的类中。
   
4. Delegate methods are neither considered as entities nor added to the entity sets of methods, since they do not offer functionality except for delegating a responsibility to another method. However, the method to which they delegate is added to the entity sets. The treatment of delegations is recursive (in the case of a chain of delegations, only the final nondelegate method is considered).
   委托方法既不被视为实体，也不被添加到方法的实体集中，因为它们除了将责任委托给其他方法外，并不提供任何功能。但是，它们委托的方法会被添加到实体集。委托的处理是递归的（在存在委托链的情况下，只考虑最后的非委托方法）。
   
5. In case of a recursive method, the method itself is not added to its entity set, since a self-invocation does not constitute a dependency with the class that the method belongs to.
   对于递归方法，方法本身不会添加到它的实体集中，因为自我调用不构成与方法所属的类的依赖关系。
   
6. Access to attributes/methods of classes outside the system boundary (e.g., library classes) is not taken into account. That is because, in our approach, the library classes are assumed to be fixed from the programmer’s perspective and, therefore, are not subject to refactoring.
   对系统边界之外的类的属性/方法的访问（例如，调用的库中的类）不会被考虑。这是因为，在我们的方法中，库类从程序员的角度被假定为是已经组织好的，所以不需要进行重构。

The similarity between a method and a class should be high when the number of common entities in their entity sets is large. In order to calculate the similarity of the entity sets, the Jaccard similarity coefficient is used. For two sets A and B, the Jaccard similarity coefficient is defined as the cardinality of the intersection divided by the cardinality of the union of the two sets
当方法和类中的公共实体数量很大时，方法和类之间的相似性应该很高。为了计算实体集的相似度，我们使用了Jaccard相似度系数。对于两个集合A和B，Jaccard相似系数定义为两个实体集交集的基数除以并集的基数

The Jaccard distance measures the dissimilarity between two sets. For two sets A and B, the Jaccard distance is defined as
Jaccard距离度量了两个集合之间的差异。对于两个集合A和B，Jaccard距离被定义为

Let e be an entity of the system, C a class of the system, and Sx the entity set of entity or class x. The distance between an entity e and a class C is calculated as follows:
设e是系统的一个实体，C是系统的一个类，Sx是实体或类x的实体集。实体e与C类之间的距离计算如下：


In this way, we ensure that all distance values range over the interval [0, 1]. If we calculate the distance between a class and an entity that belongs to it without excluding e from the entity set of the class, the intersection of their entity sets can never be equal to their union and, thus, the distance could never obtain the value 0.
这样，我们确保所有的距离值都在区间[0,1]的范围内。如果我们计算一个类和属于它的实体之间的距离，而不将e从类的实体集中排除，那么它们的实体集的交集永远不能等于它们的并集，在这种情况下，该距离永远无法得到值0。

3.2 Move Method Refactoring Preconditions

According to Opdyke [28], each refactoring is associated with a set of preconditions which ensure that the behavior of a program will be preserved after the application of the refactoring. In order to describe the preconditions that should be satisfied for a Move Method refactoring in a formal manner, we define the following set of auxiliary functions:
根据Opdyke [28]的说法，每个重构都与一组前提条件相关联，这些前提条件确保重构会保留程序的行为。为了描述以一种正式的方式进行移动方法重构所应该满足的先决条件，我们定义了以下一组辅助函数：


*In the case where class c does not explicitly inherit a superclass, then its superclass is java.lang.Object.
*在类c没有显式继承超类的情况下，那么它的超类是java.lang.Object。

*An abstract method cannot be declared as final, static, or private.
*抽象方法不能声明为final、static的或private。

*An interface may extend more than one interface.
*一个接口可以继承多个接口。

The preconditions that should be satisfied for a Move Method refactoring are divided into three categories, namely, compilation preconditions which ensure that the code will compile correctly, behavior-preservation preconditions which ensure that the behavior of the code will be preserved, and quality preconditions which ensure that certain design quality properties will not be violated. In all of the precondition functions, the method parameter (m or m1) refers to the method to be moved and the class parameter (t) refers to the target class.
移动方法重构应满足的前提条件分为三类，即确保正确编译代码的编译前提条件、确保保留代码行为的行为保存前提条件和确保不违反某些设计质量属性的质量前提条件。在所有的前提函数中，方法参数（m或m1）表示要移动的方法，类参数(t)表示目标类。

3.2.1 Compilation Preconditions

1. The target class should not contain a method having the same signature with the moved method.
   目标类不应该包含与已移动的方法具有相同签名的方法。
   
   This issue can be resolved by renaming the moved method.
   这个问题可以通过重命名已移动的方法来解决。

2. The method to be moved should not override an abstract method. Moving a method that overrides an abstract method would lead to compilation problems, since the overriding of abstract methods is obligatory for concrete classes.
   要移动的方法不应该覆盖抽象方法。移动一个覆盖抽象方法的方法将会导致编译问题，因为覆盖抽象方法对于实体类是必须的。
   
   This issue can be resolved by keeping the original method as delegate to the moved method.
   这个问题可以通过将原始方法作为对移动方法的委托来解决。

3. The method to be moved should not contain any super method invocations.
   要移动的方法不应包含任何超级方法调用。

4. The target class should not be an interface, since interfaces contain only abstract methods and not concrete ones.
   目标类不应该是一个接口，因为接口只包含抽象方法，而不包含实体方法。

3.2.2 Behavior-Preservation Preconditions

1. The target class should not inherit a method having the same signature with the moved method. Moving a method which has the same signature with an inherited method of the target class would lead to the overriding of the inherited method, affecting the behavior of the target class and its subclasses.
   目标类不应该继承与所移动的方法具有相同签名的方法。将具有相同签名的方法与目标类的继承方法移动将导致继承方法的重写，从而影响目标类及其子类的行为。
   
   This issue can be resolved by renaming the moved method.
   这个问题可以通过重命名被移动的方法来解决。

2. The method to be moved should not override an inherited method. Moving a method that overrides a concrete method would affect the behavior of the source class and its subclasses since the source class would inherit the behavior of the method defined in its superclass.
   要移动的方法不应该是override的。移动一个覆盖了实体方法的方法将影响源类及其子类的行为，因为源类从这些方法中继承了来自其超类的行为。
   
   This issue can be resolved by keeping the original method as delegate to the moved method.
   这个问题可以通过将原始方法作为移动方法的委托来解决。

3. The method to be moved should have a reference to the target class either through its parameters or through source class fields (including inherited fields) of target class type. In order to preserve the behavior of the code, the methods originally invoking the method to be moved should be modified to invoke it through that particular reference after its move. On the contrary, a local variable of target class type declared inside the body of the method to be moved cannot serve as a reference to target class, since it is not accessible outside the method.
   要移动的方法应该通过其参数或通过源类字段（包括继承字段）具有对目标类的引用。为了保留代码的行为，应该修改直接调用要移动的方法的方法，以便在移动后仍然可以通过其特定的引用来调用被移动的方法。相反，在要移动的方法体中声明的目标类类型的局部变量不能作为对目标类的引用，因为它不能在该方法之外访问。
   

4. The method to be moved should not be synchronized. The synchronization mechanism of Java ensures that when one thread is executing a synchronized method of an object, all other threads that invoke synchronized methods of the same object
   suspend the execution until the first thread is done with the object. As a result, the move of a synchronized method could create concurrency problems to the objects of the source class.
   要移动的方法不应该是synchronized的。Java的同步机制确保当一个线程执行一个对象的同步方法时，调用同一对象的同步方法的所有其他线程都会挂起执行，直到这个线程使用完该对象。因此，同步方法的移动可能会使得源类的对象产生并发问题。

3.2.3 Quality Preconditions

1. The method to be moved should not contain assignments of a source class field (including inherited fields). In that case, the assigned field cannot be passed as parameter to the moved method, since parameters are passed by value in Java, and as a result, the value of the field will not change after the invocation of the moved method. The alternative approach of passing a parameter of source class type to the moved method and invoking the setter method of the assigned field would increase the coupling between the source and target class, since the moved method would get coupled to the source class. Moreover, a method that changes the value of a field has stronger conceptual binding with the class to which the field belongs to compared to a method that simply accesses the value of the field.
   要移动的方法不应为源类字段赋值（包括继承的字段）。在这种情况下，要被赋值的字段不能作为参数传递给被移动的方法，因为参数是在Java中通过值传递的，因此，在调用被移动的方法后，该字段的值将不会改变。将源类类型的参数传递给移动的方法并调用指定字段的setter方法将增加源类和目标类之间的耦合，因为移动的方法将耦合到源类。此外，与简单地访问该字段值的方法相比，更改该字段值的方法与该字段所属的类具有更强的概念绑定。
   
2. The method to be moved should have a one-to-one relationship with the target class. In this way, a method which participates in a one-to-many composition relationship cannot be suggested to be moved from the composing class (the source class that it originally belongs to) to the contained class (target class).
   要移动的方法应该与目标类有一对一的关系。因此，不能建议将参与一对多合成关系的方法从合成类（它最初所属的源类）移动到被包含的类（目标类）。
   

3.3 Extraction of Move Method Refactoring Suggestions

The algorithm used for the extraction of Move Method refactoring suggestions is applied to all method entities of a system and consists of four main parts:
用于提取移动方法重构建议的算法适用于一个系统的所有方法实体，主要包括四个部分：

1. Identification of the set of candidate target classes T by examining the entity set of method m.
   通过检查方法m的实体集来识别候选目标类T的集合。
2. Sorting of set T according to the number of entities that method m accesses from each target class in descending order at the first level and according to the distance of method m from each target class in ascending order at the second level.
   优先根据方法m从每个目标类访问的实体数对目标类降序排列，其次根据方法m与每个目标类的距离对目标类升序排列
3. Examination of whether method m modifies a data structure in the candidate target classes.
   检查方法m是否修改了候选目标类中的数据结构。
4. Suggestion of moving method m to the first candidate target class that satisfies all of the preconditions, following the order of the sorted set T.
   建议将方法m移动到满足所有先决条件的第一个候选目标类。候选目标类的顺序参照经过排序的集合T。

It should be noted that the Jaccard distance which is used for sorting the candidate target classes when the method under examination accesses an equal number of entities from two or more classes ensures that the candidate target classes will be examined in an order that promotes the classes having fewer entities. This property is desired since it leads to the decomposition of God classes [30] and the equal redistribution of functionality among the system classes. The notion of distance is also employed as a means to rank multiple refactoring suggestions, as will be explained in Section 3.4.
应该注意的是，Jaccard距离用于排序候选目标类时，当待移动方法从两个或更多类中访问了相同数量的实体时，可以确保候选目标类将被按一定顺序检查，这有利于选择有更少实体的候选目标类。这个特性是有用的，因为它可以促进上帝类[30]的分解和系统中的类之间功能的平等再分配。距离的概念也被用作对多个重构建议进行排序，这将在第3.4节中进行解释。

The third part of the algorithm aims at identifying cases where the method under examination modifies a data structure in a candidate target class by invoking an appropriate method of the target class and passing as argument one of its parameters. In such a case, we consider that the method under examination has a strong conceptual binding with the specific target class regardless of the number of entities that the method accesses from the candidate target classes. For example, in Fig. 2a, method removeLocation(Location) has three candidate target classes, namely, TaskManager, LocationManager, and Location. It accesses one entity from each candidate target class and none from the source class. It invokes method removeLocation() through field locationManager and passes parameter loc as argument to the invoked method. More importantly, method removeLocation() of class LocationManager (Fig. 2b) actually removes the passed argument from list locations that contains objects of Location class type. As a result, class LocationManager is considered a better choice for moving the method under examination compared to the other candidate target classes.
该算法的第三部分旨在识别所检查的方法通过调用候选目标类中合适的方法并将其参数之一作为参数传递，以修改候选目标类中的数据结构的情况。在这种情况下，我们认为所检查的方法与特定目标类具有很强的概念绑定，而不管方法从候选目标类访问的概念数量如何。例如，在图2a中，方法removeLocation(Location)有三个候选目标类，即TaskManager，LocationManager和Location。它从每个候选目标类访问一个实体，从源类不访问任何实体。它通过字段locationManager调用方法removeLocation()，并将参数loc作为参数传递给被调用的方法。更重要的是，LocationManager类的方法removeLocation()（图2b）实际上从包含Location类型的对象的列表位置中删除了传递的参数。因此，与其他候选目标类相比，LocationManager类被认为是移动被检查方法的更好的选择。
A formal description of the algorithm used for the extraction of Move Method refactoring suggestions is shown in Fig. 3.
用于提取移动方法重构建议的算法的正式描述如图3所示。
Function modifiesDataStructureInTargetClass(Method m, Class t), which determines whether method m modifies a data structure in the candidate target class t, is formally described in Appendix B. Function preconditionsSatisfied (Method m, Class t) returns true if all preconditions of Section 3.2 are satisfied. In the case where method m accesses the same number of entities and has the same distance from two or more candidate target classes, then suggestions are extracted for all the classes for which the preconditions are satisfied.
函数modifiesDataStructureInTargetClass(Method m, Class t)可以确定方法m是否修改候选目标类t中的数据结构，我们在附录B中给出了该函数的正式描述。如果满足第3.2节的所有前提条件，函数preconditionsSatisfied (Method m, Class t)返回true。在方法m从多个候选目标类中分别访问相同数量的实体，且与这些候选目标类的距离相同的情况下，则对满足前提条件的所有类提取建议。

3.4 Evaluation of Refactoring Effect on Design Quality

In a large software system, it is reasonable to expect that several Move Method refactoring suggestions will be extracted. In that case, we should be able to distinguish the most effective refactorings in terms of their impact on the design.
在大型软件系统中，可以合理地提取出数种移动方法重构建议。在这种情况下，我们应该能够根据其对设计的影响来区分最有效的重构。
Our approach follows the widely accepted principle of low coupling and high cohesion [19]. To this end, the distances of the entities belonging to a class (inner entities) from the class itself should be the smallest possible (high cohesion). At the same time, the distances of the entities not belonging to a class (outer entities) from that class should be as large as possible (low coupling). This can be ensured by considering for each class the ratio of average inner to average outer entity distances. For each class, the closer to zero this ratio is, the safer it is is to conclude that inner entities have correctly been placed inside the class and outer entities to other classes. A formula that provides the above information for a class C is given by
我们的方法遵循了被广泛接受的低耦合和高内聚[19]的原则。为此，属于类的实体（内部实体）与类本身的距离应该是最小的（高内聚性）。同时，不属于类（外部实体）的实体与该类的距离应尽可能大（低耦合）。这可以通过考虑每个类的平均内部实体距离与平均外部实体距离的比率来确保。对于每个类，这个比率越接近于零，就越安全地认为内部实体已经被正确地放置在类中，而外部实体则属于其他类。提供上述信息的公式为：

where e denotes an entity of the system. In the special casewhere a class does not have inner entities, the aboveformula cannot be calculated.
其中，e表示系统的一个实体。在类没有内部实体的特殊情况下，无法计算上述公式。
The weighted metric for the entire system which considers the number of entities in each class is given by
整个系统中每个类中实体数量的加权度量值由以下公式给出：

The lower the value of this metric is, the more effective the specific refactoring for the entire system is. The classes that do not have inner entities are not included in the above metric.
这个度量的值越低，对整个系统的特定重构就越有效。没有内部实体的类不包括在上述度量中。

3.5 Virtual Application of Move Method Refactoring Suggestions

In order to evaluate which of the Move Method refactoring suggestions are the most effective ones, we could apply each one of them on source code and then recalculate the distances between the entities and the classes to measure the Entity Placement metric for each of the resulting systems. However, the actual application of the suggested refactorings on source code adds a significant overhead due to disk write operations (once for applying each refactoring and once for undoing it).
为了评估哪一种移动方法重构建议是最有效的，我们可以将它们分别应用到源代码上，然后重新计算实体和类之间的距离，以度量每个结果系统的实体放置度量。但是，由于磁盘写操作很可能会进行两次（一次应用重构，一次撤销重构），增加了巨大的开销。
To overcome this problem, all suggested refactorings are virtually applied. This is achieved by updating the entity sets of the entities/classes which are involved in the move of the corresponding method and calculating the Entity Placement metric for the resulting entity sets.
为了克服这个问题，所有建议的重构都被实际应用。这是通过更新被移动的方法所涉及的实体/类的实体集，和计算结果实体集的实体放置度量来实现的。
The virtual move of a method from the source class to a target class is performed as follows:
方法从源类到目标类的虚拟移动规则如下：

1. The tag indicating to which class the method belongs is changed from source class to target class.
   该方法所属的类的标记将被从源类更改为目标类。
2. The entity sets of all methods accessing the method are updated according to the new tag.
   访问该方法的所有方法的实体集都将根据新的标记进行更新。
3. The entity sets of all attributes that are being accessed by the method are updated according to the new tag.
   该方法正在访问的所有属性的实体集将根据新标记进行更新。
4. The method is removed from the entity set of the source class.
   该方法将从源类的实体集中删除。
5. The method is added to the entity set of the target class.
   该方法将被添加到目标类的实体集中。

The distances which have to be recalculated after the virtual application of a refactoring are: 1) the distances from the source and the target class of the entities whose entity set has been affected from the virtual application (i.e., methods that access the moved method and fields being accessed from the moved method) and 2) the distances from the source and the target class of the entities whose entity set contains at least one entity of the source and/or the target class. The rest of the distances remain unchanged since the entity sets of the classes that do not participate in the refactoring are the same compared to the initial system.
对重构进行虚拟应用之后必须重新计算的距离包括：1)其实体集被虚拟应用所影响的实体与（被移动方法的）源类和目标类的距离。（比如，调用了被移动方法的方法，以及被移动方法所访问的字段）2）其实体集包含源和/或目标类的至少一个实体的实体与（被移动方法的）源类和目标类的距离。其余的距离保持不变，因为不参与重构的类的实体集与初始系统相比是相同的。
The extracted refactoring suggestions are ranked in an ascending order according to the corresponding Entity Placement metric values. Eventually, all refactoring suggestions for which the resulting system has a lower Entity Placement value than the current system are considered as refactorings that can improve the design of the system.
提取的重构建议根据相应的实体位置度量值按升序排列。最终，所有实体放置度量值低于当前系统的重构建议都被认为是可以改进系统设计的重构建议。

3.6 Demonstration of the Methodology on a Refactoring Teaching Example

To demonstrate the application of the methodology, we have used a widely known example for refactorings, namely, Fowler’s Video Store [17]. The initial version of the program is intentionally not well designed. Its design is gradually improved by applying successive refactorings. We have taken a snapshot of the evolving system exactly before the application of the first Move Method refactoring.
为了演示上述方法的应用，我们使用了一个众所周知的重构示例，即Fowler的视频商店[17]。该程序的最初版本故意没有设计得很好。通过连续应用重构方法，逐步改进了其设计。在应用第一步移动方法重构之前，我们已经对演化系统进行了一个快照。
The UML class diagram of the snapshot that we examined is shown in Fig. 4. The arrow indicates the move of method getCharge(Rental) from class Customer to class Rental, as suggested by the author of the example.
我们所检查的快照的UML类图如图4所示。箭头表示方法getCharge(Rental)从Customer类到Rental类的移动，如示例的作者所建议的那样。
To calculate the distances between the entities and the classes of the system, we need first to construct their entity sets, as shown in Table 1. The entity set of each entity contains the attributes and methods that it accesses (if it is a method) and the methods accessing it (if it is an attribute).
为了计算实体和系统类之间的距离，我们首先需要构造它们的实体集，如表1所示。每个实体的实体集都包含它所访问的属性和方法（如果该实体是方法）以及访问它的方法（如果该实体是属性）。
As can be observed from Table 1, the attributes that are references to classes of the system, namely, Customer::_rentals and Rental::_movie are not considered as entities and do not participate in the entity sets of other system entities. The getter and setter methods of the system, namely, Customer::addRental(Rental), Customer::getName(), Rental:: getDaysRented(), Rental::getMovie(), Movie:: getPriceCode(), Movie::getTitle(), Movie::setPriceCode() are also not considered as entities. However, the attributes to which they provide access (Customer::_name, Rental::_daysRented, Movie::_priceCode, Movie::_title) are added to the entity sets of the system entities. The static attributes Movie::CHILDRENS, Movie::NEW_RELEASE and Movie::REGULAR are also not considered as entities and do not participate in the entity sets of the system entities accessing them. Finally, the method Customer:: amountFor(Rental) that delegates to Customer::getCharge(Rental) is not considered as entity and its invocation from method Customer::statement() is replaced with the method that it delegates to.
从表1中可以看出，系统中的类的引用，即Customer::_rentals和Rental::_movie不被视为实体，也不参与其他系统实体的实体集。系统中的的getter和setter方法，即，Customer::addRental(Rental), Customer::getName(), Rental:: getDaysRented(), Rental::getMovie(), Movie:: getPriceCode(), Movie::getTitle(), Movie::setPriceCode()也不被视为实体。但是，它们提供访问的属性（Customer::_name, Rental::_daysRented, Movie::_priceCode, Movie::_title)被添加到了系统实体的实体集中。静态属性Movie::CHILDRENS, Movie::NEW_RELEASE and Movie::REGULAR也不被视为实体，也不参与访问它们的系统实体的实体集。最后，委托Customer:: amountFor(Rental)的Customer::getCharge(Rental)也不被视为实体，其从方法Customer::statement()的调用将被替换为其委托的方法。
To extract refactoring suggestions for method Customer::getCharge(Rental), a set of candidate target classes T should be identified by examining its entity set.
要提取方法Customer::getCharge(Rental)的重构建议，应该通过检查其实体集来获取一组候选目标类T。
The entity set of method getCharge(Rental) is
方法getCharge(Rental)的实体集是：

and, consequently, the set of candidate target classes for getCharge(Rental) is
因此，getCharge(Rental)的候选目标类的集合是：

Since method getCharge(Rental) accesses an equal number of entities from both candidate target classes (i.e., entity _priceCode from Movie and _daysRented from Rental), the two candidate target classes will be sorted according to their distance from method getCharge(Rental).
由于方法getCharge(Rental)访问的两个候选目标类的实体数量相同（即Movie类中的实体_priceCode和Rental类中的实体_daysRented），因此两个候选目标类将根据它们与方法getCharge(Rental)的距离进行排序。

The distances between method Customer::getCharge(Rental) and the candidate target classes are calculated as:
方法Customer::getCharge(Rental)与候选目标类别之间的距离计算为：

The target class having the lowest distance from method getCharge(Rental) is Rental and, since all preconditions are satisfied with the specific target class, a Move Method refactoring suggestion is extracted, indicating the move of method getCharge(Rental) to class Rental. The second candidate target class Movie will not be examined by the algorithm since a Move Method refactoring suggestion has been already extracted. However, it should be noted that if class Movie was examined as target class, the preconditions would not be satisfied since method getCharge(Rental) has a local reference to class Movie which is not accessible outside the method.
与方法getCharge(Rental)距离最小的目标类是Rental，由于满足所有前提条件，因此提取移动方法重构建议，指示方法getCharge(Rental)到Rental类的移动。第二个候选目标类Movie将不会被算法检查，因为已经提取了一个移动方法重构建议。但是，需要注意的是，如果将Movie作为目标类进行检查，前提条件将不被满足，因为方法getCharge(Rental)有一个Movie类的局部引用，在方法之外无法访问。

4 JDEODORANT ECLIPSE PLUG-IN

The proposed methodology has been implemented as an Eclipse plug-in [1], [16] that not only identifies Feature Envy bad smells but also allows the user to apply the refactorings that resolve them on source code. Moreover, the tool preevaluates the effect on design quality of all refactoring suggestions, assisting the user to determine the most effective sequence of refactoring applications. The plug-in employs the ASTParser of Eclipse Java Development Tools (JDT) to analyze the source code of Java projects and the ASTRewrite to apply the refactorings and provide undo functionality. JDeodorant offers some novel features concerning the application of Move Method refactorings:
本文提出的方法已经作为一个Eclipse插件[1]，[16]实现，它不仅识别特性嫉妒的坏气味，还允许用户在源代码上应用与解析重构操作。此外，该工具还预先评估了所有重构建议对设计质量的影响，帮助用户确定最有效的重构应用程序序列。该插件使用Eclipse Java开发工具（JDT）中的ASTParser来分析Java项目的源代码，并使用ASTRewrite来应用重构并提供撤销功能。JDeodorant对移动方法重构的应用提供了一些新的特点：

1. It automatically determines whether the original method should be turned into a method that delegates to the moved one. The delegate method is necessary when other classes apart from the source class invoke the method to be moved and it prevents these classes from changing the way in which they invoke the moved method.
   它会自动确定是否应该将原始方法转换为委托给已移动方法的方法。当除源类之外的其他类调用要移动的方法时，委托方法是必要的，并且它可以防止这些类更改它们调用要移动的方法的方式。
2. It automatically identifies dependencies between the refactoring suggestions and provides tooltip support aiding the user to resolve them (Fig. 5). For example, if the method associated with refactoring suggestion X invokes a method which is associated with another Move Method refactoring suggestion Y , a tooltip informs that suggestion Y (corresponding to the invoked method) should be applied before X (corresponding to the invoking method).
   它会自动识别重构建议之间的依赖关系，并提供工具提示支持，以帮助用户解决它们（图5）。例如，如果与重构建议X相关联的方法调用了与另一个移动方法重构建议Y相关联的方法，则工具提示建议Y（对应于被调方法）的应用应当先于建议X（对应于主调方法）。
3. It automatically moves to the target class all of the private methods of the source class which are invoked only by the moved method.
   它会自动将只被待移动方法调用的源类私有方法移动到目标类。
4. When the user inspects a method which is suggested to be moved, the tool provides tooltip support indicating the number of members that it accesses from each class (Fig. 6). In this way, the user can more easily realize the Feature Envy problem.
   当用户检查建议移动的方法时，该工具将提供支持，指示待移动方法从每个类访问的成员数量（图6）。这样，用户就可以更容易地发现特性嫉妒问题。