Optimized Refactoring Mechanisms to Improve Quality Characteristics in Object-Oriented Systems

Refactoring has emerged as a predominant approach to augmenting software product quality. However, empirical evidence suggests that not all dimensions of software quality experience unending enhancements through refactoring. Current scholarly explorations reveal significant variances in the impacts of diverse refactoring methods, with potential adverse effects and contradictions surfacing concerning software quality. Consequently, such disparities render the advantages of refactoring contentious, culminating in challenges for software developers in the selection of optimal refactoring methods to ameliorate software quality. Existing literature lacks an in-depth exploration of the reasons behind the contrasting impacts of refactoring methods on quality enhancement or the development of refined protocols for employing these techniques. Therefore, this research aims to explore, identify, and fine-tune the utilization mechanisms of refactoring methods, empowering software developers to make informed choices for the enhancement of object-oriented systems’ quality attributes. Ten commonly employed refactoring methods were singled out for this investigation, each executed independently across five case studies varying in scale (small, medium, and large). The Quality Model for Object-Oriented Design (QMOOD) was employed as the evaluation tool to ascertain the influence of refactoring techniques on quality attributes. The research outcomes denote that the multifarious impacts of refactoring methods on quality attributes are attributed to distinct usage mechanisms of the techniques. These insights assist software practitioners in discerning the optimal utilization of refactoring methods to ameliorate software quality, taking their mechanisms into account. Moreover, these outcomes furnish industry experts with prescriptive guidelines for employing refactoring methods to elevate the quality of object-oriented systems, predicated on the suitable mechanism.


I. INTRODUCTION
Changes to the software systems' codes and related documentation are always the results of an issue or the need The associate editor coordinating the review of this manuscript and approving it for publication was Hailong Sun .
for enhancement [1], [2].As a result, software maintenance is now an essential part of the creation and operation of software systems [3], [4], as well as a required task for every software application [5].The maintenance cycle is made up of critical actions that are intended to ensure the dependability of modern software systems [6].The incremental changes were intended to improve certain features, correct any design flaws, or address any other issues [2], [6].The complexity of such software maintenance tasks grows in proportion to the system's size and number of responsibilities [6].Indeed, approximately 80% of the overall expenses in software development can be attributed to maintenance and evolution endeavors, as indicated by previous research [2], [7], [8], [9].Additionally, it has been established that software professionals often allocate about 60% of their time and resources to comprehending the software they are responsible for maintaining and supporting [9], [10].Unstructured coding poses significant challenges and is acknowledged as a primary cause of maintenance issues, leading to a substantial escalation in maintenance expenses [2], [11].The impact of inadequate system design is staggering, with estimations suggesting a cost exceeding USD 150 billion annually in the United States alone and surpassing USD 500 billion on a global scale [12].
Luckily, the refactoring process has the potential to significantly reduce the cost of system maintenance and evolutionary operations [7], [13], [14].Refactoring is regarded as one of the most important techniques for maintaining and evolving software [15], [16], and it has evolved into an essential component of software development practices, particularly given the dynamic nature of user and information technology (IT) requirements [10].Refactoring serves as a methodology for enhancing the design quality of software systems.It achieves this by restructuring the internal setup of software applications, without affecting their operational functionality.According to Fowler et al. [17], [18], there exist 68 distinct refactoring methods that have been categorized into six different groups.According to the refactoring definition, it is closely related to software quality characteristics [5].Earlier empirical studies in this context investigated how refactoring methods affected several software quality characteristics [16], [19].The related studies, in particular, investigated whether either refactoring method improved both external and internal quality characteristics.Several studies produced contradictory results, according to an analysis of the relevant literature, such as: • Refactoring methods improve software quality [20], [21], [22], [23], [24].
Several studies have discovered that different refactoring methods have varying and distinct effects on software quality characteristics.As a result, scientists disagree about the impact of refactoring methods on external and internal quality characteristics.Although some studies have shown that refactoring methods improve software quality, others argue that this is not always the case [13], [33].To put it another way, the evidence for the benefits of refactoring is conflicting [34].
Refactoring enhances the quality of the software by making the code more maintainable, readable, and efficient.It involves tasks such as removing code duplications, renaming ambiguous variables and functions, and applying appropriate design patterns.These changes reduce complexity, make it easier to understand the code, and result in improved performance and an overall enhancement of the software's quality.However, there are some reasons why software quality may not be improved through refactoring.These may include different scenarios and mechanisms for applying refactoring methods, different effects of refactoring methods, fundamental design flaws, insufficient or unclear requirements, and a lack of resources such as time and budget.
In the literature, there has been no research or analysis of the factors that produce the varying effects of refactoring methods on software quality characteristics.As a result, this study used experiments to look at and evaluate how the factor of mechanisms affects the use of refactoring methods.The goal was to figure out how this factor affects the different effects that refactoring methods have on quality characteristics.
The rest of this paper is organized as follows: Section II discusses related works, while Section III describes the methodology.Section IV goes over the results.Section V examines the threats to validity.Section VI presents the conclusions and outlines the future research objectives.

II. RELATED WORK
Researchers have identified various factors that could be involved in the varying impacts of refactoring methods on quality characteristics.These factors have been discussed below:

A. REFACTORING TOOLS
The usage of the current refactoring tools, according to Kim et al. [34], [41], may lead to wrongly refactored code portions since they are error-prone.As a result, using these tools might occasionally harm the level of code quality [33].
As an example, a study [42] found that when they utilized the Miner tool to apply the Move Method refactoring method, the complexity of the software system rose.In other words, the Move Method has increased the system's complexity.Contrarily, Chavez, et al. [43] applied the Move Method using the JDeodorant tool and found that it did not affect complexity.This means that refactoring methods may have a different impact on quality characteristics depending on the tools used to apply them.

B. SOFTWARE SIZE
The number of classes in an object-oriented software system determines its size.In the refactoring research studies, 99144 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
various system sizes (large, medium, and small) have been utilized.As a result of this, using refactoring methods on software systems of various sizes may have various effects on quality characteristics.The usage of software applications of varying sizes, according to Kaur and Singh [13], maybe one of the causes of contradictory or diverging conclusions concerning the impact of refactoring on the quality of software.To classify refactoring methods according to certain software quality characteristics, studies [35], [44] exclusively utilized the refactoring methods for small software systems at the level of classes.As a consequence, they suggested that the usage of the small-size system may be an issue when examining how refactoring methods affect the system level [31], [35], [44], [45].Refactoring methods were utilized at the class level by Kumari and Saha [46], who highlighted that outcomes may vary when used at the system level.

C. MECHANISMS OF APPLYING REFACTORING TECHNIQUES
The mechanisms of each refactoring method were described by Fowler et al. [17], [18].There are various mechanisms for applying some refactoring methods.For example, depending on the method access modifier, the Move Field has various mechanisms for transferring it (i.e., protected, public, and private).There are various mechanisms for inlining the inline method, such as inlining the public methods or inlining the private or protected methods.Al Dallal and Abdin [33] claim that several techniques are now in use for applying refactoring mechanisms to specific refactoring methods and that these techniques may result in various refactored code portions.
Almogahed et al. [40] conducted an experimental study to investigate different scenarios for using ten refactoring methods.They found that refactoring methods can be used in different scenarios, and they presented compelling evidence indicating that the application of a refactoring method under varying scenarios leads to different outcomes on quality.
According to Oliveira et al. [47], [48], the mechanisms of the refactoring method result in various outcomes when used by integrated development environment (IDE) developers.Depending on the mechanism used to implement the refactoring method, a study [46] claims that refactoring's effects on quality characteristics might differ.As a result, various mechanisms of refactoring method application can have varying impacts on quality characteristics.Nevertheless, there is no empirical evidence in the literature to prove or disprove that the mechanisms used to apply refactoring methods have an effect on quality characteristics.
In light of this, the current research builds upon our previous study [40] by conducting a comprehensive empirical investigation to examine and assess in depth the impact of refactoring method utilization mechanisms on the diverse effects of refactoring methods on quality attributes.Notably, this study explores refactoring methods that were not examined in previous research endeavors.

III. METHODOLOGY
This part describes the approach used to carry out this research.As seen in Fig. 1, the much more popular refactoring methods were initially picked.Second, five case studies of various sizes have been collected.Third, the values of object-oriented measurements have been gathered, and external quality characteristics have been computed before and after the refactoring methods have been applied to the code.In step four, each refactoring method's specific effects on each internal and external quality characteristic were carefully examined.In step five, a multi-case analysis was used to determine how each refactoring method had an overall effect.The effects of each refactoring method have also been established while accounting for the factor under investigation.The following subsections contain a detailed discussion of the steps that made up this experimental design.

A. CHOOSING REFACTORING METHODS
There are 68 unique refactoring methods that Fowler et al. [17] have proposed.Depending on the results of an extensive review of the literature on frequently utilized refactoring methods carried out by [13] and [33], along with survey results regarding the popular refactoring methods currently being used among industry experts conducted by [40], ten refactoring techniques have been selected for this investigation.Following are brief explanations of each of the ten refactoring methods that were selected: 1. Add Parameter (AP): When a method requests extra data from its caller, this technique is applied.Provide a parameter for an object that may transmit this data.
2. Encapsulate Field (EF): By altering the public fields' accessibility, this method is applied to restrict data access.It offers two accessors' methods and converts the field access from public to private.
3. Extract Class (EC): This method is used to create a new class when an existing one is too big and has too many duties, causing it to perform duties that two classes should perform.The first class's relevant methods and fields are carried over to the new class.
4. Extract Superclass (ESP): When two classes have fields and methods that are similar, this technique is applied to generate a superclass and transfer the shared fields and methods to the superclass.
5. Hide Method (HM): Other classes don't utilize a method or only use it within the class hierarchy of the class it belongs to.This technique is used to protect or make the method private.
6. Inline Class (IC): A class is not responsible for anything, and there are no plans to make it so.This technique copies all of the class's methods and fields to another class and then deletes it.
7. Inline Method (IM): When the method's body is simpler to grasp than that of the method itself, this method is used.It deletes the method itself and replaces all method calls with the method's content.
8. Move Field (MF): This method moves a field from a primary class to an appropriate class and updates all of its users when a field is present in one class but frequently utilized in another.9. Remove Parameter (RP): When the method body no longer uses a parameter, this strategy is applied.It eliminates the extra parameter.
10. Rename Method (MM): When a method's name does not give away its purpose, this method is used to change the name so that it does.

B. SELECTING CASE STUDIES
For the experimental investigation, five case studies of various sizes (large, medium, and small) and from two distinct contexts (academic and open source) have been chosen.The inclusion of projects from academia was motivated by their restricted extension as well as the ability to examine the structure and design of the project's code [49].The selection of jHotDraw and jEdit as case studies for this research was guided by their recurrent usage in refactoring research, as established by numerous exhaustive literature reviews [5], [13], [33], [50].
Additionally, the five case studies have been chosen in small, medium, and large sizes to explore the effects of refactoring methods on the quality characteristics of software systems using various case study sizes.The following is a description of the chosen case studies: 1. Payroll Management System (PMS) [51]: Twelve classes make up this small software system that three postgraduate students in the IT department created.The goal of the application was to offer a simple method for automating all payroll-related tasks for the employees as well as a fully complete system to assist with organizational administration.
2. Library Management System (LMS) [52]: LMS is comprised of 19 Java classes and is of a small size.Managing and arranging library activities is possible using the system.LMS includes MySql database capability, allowing it to keep the database updated by adding books and maintaining track of books that were gathered or published.
3. Bank Management System (BMS) [53]: It is a Javawritten, compact computer-based system with 34 classes.The BMS is developed to handle all the essential data needed to compute monthly account statements for customers.It offers a variety of services to customers, including meeting every bank's procedural needs and boosting bank productivity.
4. jHotDraw [54]: This is a medium-sized open-source application (250 classes).jHotDraw is a graphical framework for creating ordered two-dimensional drawings.It provides a fundamental blueprint for a visual interface designer with tool palettes, numerous views, user-defined visual representations, and assistance with storing, loading, and printing sketches.
5. jEdit [55]: With 1153 classes, it is a large open-source application that supports Java.jEdit is a Java-based text editor designed for programmers.The cross-platform text editor jEdit includes numerous capabilities, including a comprehensive plugin framework, syntax highlighters for 130 languages, constructed macro languages, and comprehensive encoding capabilities.

C. SELECTING QUALITY CHARACTERISTICS
To achieve the overall goals of this study, a quality model that can assess the quality characteristics of object-oriented applications and the influence of refactoring methods on such applications is required.The quality models must be capable of quantifying estimations of external quality characteristics in addition to measuring internal quality characteristics.As a consequence, the Quality Model for Object-Oriented Design (QMOOD) [56], a commonly used model that can evaluate 99146 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
the quality of software design [57], is a better fit for this study.The QMOOD covering is made feasible by its own six external quality characteristics as well as 11 internal design aspects that, taken together, provide a more complete view of the software's quality than the earlier quality systems of measurement for object-oriented design [58].It has widely adopted metrics that are meant to measure software design at the class and system levels [59].Those measurements are also very useful in identifying flaws in conventional as well as continuous software development methods [60].Additionally, it has the capability of assessing the entire quality of software systems.Accordingly, all object-oriented measurements, internal quality characteristics, and external quality characteristics that are part of the QMOOD were used for this investigation.Table 1 lists the internal quality characteristics, as well as the metrics to which they are linked and how those measurements have been used to assess the corresponding internal quality characteristics.The following are the descriptions of the six external attributes included: 1. Reusability: This refers to the extent to which components of the system can be assimilated with other components within a system.
2. Flexibility: It denotes the ease with which system components can be modified for usage in contexts other than their original design intentions.
3. Effectiveness: The extent to which the design may be made to conform to desired behavior and functionality utilizing object-oriented principles.
4. Extendibility: This represents the straightforwardness with which fresh demands can be incorporated into the existing design.To expand the capabilities of system components, provisions for upgrades must be feasible.
5. Understandability: The features of the software's design that make it simple to understand.
6. Functionality: duties allocated for design classes that may be accessible through the public interface Table 2 shows the math equations that were used to make an objective evaluation of the chosen external quality characteristic based on the internal quality measurements.
Before and following the application of the refactoring methods, QMOOD measurements have been gathered, and the external quality characteristics and TQI have been computed utilizing mathematical formulae supplied by QMOOD to assess their influences on the external and internal quality characteristics.It is possible to assess if a refactoring method had a positive, negative, or ineffective influence on quality measurement values by subtracting the pre-refactoring quality measurement values from the post-refactoring quality measurement values.The refactoring method has a positive effect on a quality characteristic if the difference has a positive value (except for coupling and complexity).The refactoring method harms the quality characteristic if the difference has a negative value (except for coupling and complexity).Both the TQI and the external quality characteristics are unaffected by the refactoring method if the difference is 0. To collect the QMOOD measurements for this study, the Eclipse Metrics 1.3.8tool [61] was selected as it is one of the Java tools that are most regularly used in research fields and is compatible with the commonly utilized environments, including Linux and Windows [62].

D. APPLYING REFACTORING METHODS
The effects of the selected refactoring methods on TQI, external quality characteristics, and internal quality characteristics have each been individually tested.For each refactoring method, Fowler provided guidance detailing how to use it [17], [18].Refactoring may be carried out either manually or through the use of tools.Five refactoring methods (Add Parameter, Encapsulate Field, Hide Method, Remove Parameter, and Rename Method) have been carried out using the Eclipse refactoring tool [63].The usage of refactoring is continuously being improved via the Eclipse refactoring tool [5].One refactoring technique (Extract Class) has been carried out using the JDeodorant tool [64].JDeodorant is the most commonly used refactoring tool [5].A manual validation, however, was done to make sure the refactoring methods were carried out in line with the mechanisms suggested by Fowler et al. [17], [18].The rest of the refactoring methods (Move Field, Inline Method, Extract Superclass, and Inline VOLUME 11, 2023 99147 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Class) have been performed manually based on the principles outlined by Fowler et al. [17], [18] due to the absence of automated tools.Furthermore, two steps were taken in precise order to guarantee that the behavior of the system was preserved following the use of every refactoring method: 1) executing the code base, and; 2) examining the outputs of the system.
The system's source code was automatically built using the Java compiler in the Eclipse IDE as part of the compilation process to guarantee that it remains error-free after every refactoring method was applied.To ensure that the system still functions as it did before refactoring, the system has been executed, and its outcomes have been examined using its interface.

E. MULTI-CASE ANALYSIS USING FIVE CASE STUDIES TO EXAMINE THE MECHANISMS OF USING REFACTORING METHODS
An effective approach for determining the underlying mechanisms of complex phenomena or systems is multi-case analysis [65], [66], [67], [68].This approach allows researchers to comprehend the theoretical underpinnings of novel events or phenomena.Examining the mechanisms of how applying refactoring methods affects the quality of software systems is the main objective of the multi-case analysis in this study.Concerning the mechanisms of applying the refactoring methods factor, applying the refactoring methods with various mechanisms, depending on various explored opportunities, were identified and investigated through multiple case studies.Concerning the mechanisms of applying the refactoring methods factor, various mechanisms were identified and investigated through multiple case studies, depending on various explored opportunities.Different mechanisms for using refactoring techniques were discovered due to the different case study designs.The influences of refactoring methods with various mechanisms on software quality characteristics have been then investigated to ascertain if refactoring methods with various mechanisms had diverse influences on quality assurance.

IV. RESULTS AND DISCUSSION
To examine the various factors that influence how refactoring methods affect quality characteristics, this paper examined five case studies.Every one of the 10 refactoring methods was applied separately.In five case studies, this paper conducted 43 experiments: eight in the LMS, six in the BMS, nine in the PMS, ten in jHotDraw, and ten in jEdit.An experiment means utilizing a case study to look at how each refactoring method affects certain quality criteria.The overall number of refactoring methods utilized in a case study is equal to the number of experiments conducted in that case study.Table 3 displays the summary statistics of the TQI, external, and internal quality characteristics that were calculated before using the 10 refactoring methods across the five case studies.A descriptive analysis of the frequency with which every refactoring method was utilized in the five case studies is shown in Table 4.Following the implementation of the refactoring methods, the metrics and external quality characteristics (including TQI) are represented numerically in Table 5 and Table 6, respectively.The impacts of refactoring methods on metrics and external quality characteristics (including TQI) are shown in Tables 7 and 8, respectively.In Tables 7 and 8, the symbol (↑) indicates that the refactoring method enhances the quality attribute (except NOM and DCC), the symbol (↓) indicates that the refactoring method degrades the characteristic (except NOM and DCC), and the symbol (−) indicates that there is no change in quality.
The factors that have contributed to the several impacts of refactoring methods on the quality characteristics that were identified, investigated, and analyzed through experiments and multi-case analysis over the five case studies are discussed in the subsection that follows to assess their influence on the use of refactoring methods on software quality characteristics.

A. MECHANISMS OF APPLYING REFACTORING METHODS FACTOR
Mechanisms for applying every refactoring method were suggested by Fowler et al. [17], [18].Such mechanisms lay out the procedures that must be followed to use the refactoring methods appropriately.Nevertheless, those mechanisms run into various internal software system designs, and as a result, depending on the internal software system design, those mechanisms may be executed in various ways.The internal building blocks of a system are classes, functions, and variables.The number of properties and their kinds, the number of functions and their forms, and the connection between them vary from class to class in the inner class design.

VOLUME 11, 2023
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Additionally, different relationships exist between each class and the other classes, even within the same system.Every class differs from the others regarding coupling, composition, and cohesiveness.
As a result, five refactoring techniques (Move Field, Encapsulate Field, Inline Method, Inline Class, and Extract Superclass) encounter different internal class designs; consequently, they have various mechanisms to use (e.g., object pointers, method declarations, data formats, method kinds, variable accessibility modifiers, and class relationships).On the other hand, each of the five refactoring techniques (Add Parameter, Extract Class, Hide Method, Remove Parameter, and Rename Method) has only one mechanism to work, no matter how the internal design of the class is set up.This means that they all have the same effect on the quality of the software.The various mechanisms for using the refactoring methods were examined and evaluated.The findings demonstrate that the influence of using these refactoring methods in various mechanisms on quality characteristics varies.To put it another way, varying mechanisms for applying refactoring methods contribute to the different impacts of refactoring methods on quality characteristics.The following sections go over the various mechanisms for utilizing related refactoring techniques.

1) ADD PARAMETER (AP)
The AP intends to provide a parameter for a data-transmitting object.As a result, the AP has only one mechanism (M1) through which it can be used.The application mechanism is to add a new parameter to the identified method in order to transfer the required data.The effect of applying the AP via this mechanism has been determined.The relationship between AP and the associated quality characteristics is shown in Table 9 with the symbols (↑) labeling quality improvement (except for DCC and NOM), (↓) labeling quality reduction (except for DCC and NOM), and (−) labeling no changes in quality characteristics.The total applied indicates the overall number of times the AP was applied throughout the five case studies.
The findings show that AP enhances understandability, functionality, reusability, and TQI by increasing cohesion.VOLUME 11, 2023 99149 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

2) ENCAPSULATE FIELD (EF)
The EF aims to limit access to the field from outside the class.To reach this aim, the public or default type of fields should be encapsulated.Therefore, there are three mechanisms to use the EF: 1) mechanism 1 (M1): encapsulation of the public fields; 2) mechanism 2 (M2): encapsulation of the public static fields; and 3) mechanism 3 (M3): encapsulation of the default fields.The effect of using the EF through the three mechanisms has been identified.Findings reveal that EF improves the TQI in all the mechanisms; however, different mechanisms have different effects on DAM, CAM, NOM, flexibility, effectiveness, and understandability.Table 10 displays the influence of EF on the three mechanisms.
The EF does not change the DAM in M2 and M3 because QMOOD sets the same values for static, default, and private fields to calculate the DAM; therefore, flexibility and effectiveness are not affected.The NOM does not affect M2 because the static methods are not counted in the NOM; consequently, the understandability is not affected.It should be noted that the M1 is the most commonly used.

3) EXTRACT CLASS (EC)
When an existing class is too large or has too many responsibilities, the EC is used to create a new one.Therefore, there is one mechanism (M1) to perform the EC.In this mechanism, the responsibilities of the large class are divided, and a new class is created.The associated methods and fields are transferred from the source class (the large class) to the new class.The influence of applying the EC through this mechanism has been identified.Table 11 depicts the influence of EC on the related quality characteristics through this mechanism.
According to the findings, the EC increased DSC, CIS, CAM, DAM, DCC, and NOM while decreasing ANA.As a result, extendibility and understandability get worse, while reusability, flexibility, effectiveness, functionality, and TQI get better.99150 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.TABLE 6. External quality characteristics and TQI post-using the refactoring method (RM).

4) EXTRACT SUPERCLASS (ESP)
The ESP is used where two or more classes have similar common features (attributes and methods).Common methods are either private, protected, or mixed with the public.Therefore, the ESP can be used in two mechanisms (M): 1) M1: all common methods extracted to the superclass are private or protected; 2) M2: the methods extracted to the superclass are public or mixed (public and private).The results are presented in Table 12 and indicate how the ESP affects quality characteristics in both mechanisms.
The ESP improves the TQI in M1 while impairing the TQI in M2.In S2, the ESP reduces messaging (CIS) dramatically, as the common methods extracted from the subclasses to the superclass are public, and therefore the reusability and functionality are reduced, which in turn weakens the TQI of the system.

5) HIDE METHOD (HM)
The goal of the HM is to keep the methods private or protected.As a result, there is one mechanism (M1) to apply the HM.In this mechanism, the access modifier of the method is made private.The impact of using the HM via this mechanism has been identified.Table 13 shows how HM affects the related quality attributes through this mechanism.
The findings show that HM reduced messaging (CIS), thereby impairing reusability, functionality, and TQI.

6) INLINE CLASS (IC)
The reason for using an Inline Class is that a class does almost nothing and is not responsible for anything.There are two mechanisms (M) for inlining a class.1) mechanism 1 (M1): the target class is slightly coherent, in which the methods are related to some extent, and 2) mechanism 2 (M2): the class is non-cohesive (a zero-cohesion class), in which no methods or a small number of methods are not related to each other.Findings show that applying the IC to M1 reduces the cohesion of the system while applying the IC to M2 does not affect the cohesion of the system.Table 14 presents the influence of the IC in both mechanisms.Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Applying IC mechanisms is almost the for the effect on attributes, except for a very slight difference in cohesion.M1 is the most widely used in this study because most of the opportunities identified belong to M1.

7) INLINE METHOD (IM)
The Inline Method is the inverse of the Extract Method.Therefore, four mechanisms have been identified, and their effects on the quality attributes have been determined.These mechanisms are 1) inlining the public methods (M1), 2) inlining the private or protected methods (M2), 3) inlining the public static methods (M3), and 4) inlining the public methods along with the de-encapsulation of the related field if it is required (M4).The results demonstrate that various IM usage mechanisms affect quality characteristics differently.Table 15 summarizes the outcomes of IM use within each mechanism.
In most mechanisms, the IM harms the overall system quality as evaluated by TQI.The IM improves the TQI in M2, but this mechanism is rare because most methods in a system are public.

8) MOVE FIELD (MF)
There are three mechanisms for using the Move Field.Each mechanism for using MF is applied based on its opportunity.These mechanisms (M) are: 1) move public fields (M1), 2) VOLUME XX, 2017 9 move public static fields (M2), and 3) move private fields (M3).Each mechanism has identified the MF effect.The results reveal that various mechanisms have varying impacts on quality characteristics.Table 16 presents how MF affects the relevant mechanism.
The MF commonly improves the TQI, as is clear in both M1 and M2.In M3, the effect of MF is dynamic (D), depending on the encapsulation situation (number of private fields) of the source and target classes.DAM does not change when all fields in the source and target classes are private.When there are more private fields in the source class than there are public fields and fewer private fields in the destination class than there are public fields, DAM increases.When there are more private fields in the target class than there are public fields and fewer private fields in the source class than there are public fields, DAM decreases.Therefore, flexibility, effectiveness, understandability, and TQI are affected by changes in the DAM.

9) REMOVE PARAMETER
The RP aims to remove the parameter that is not utilized in the method body.One mechanism (M1) is used to perform the RP.The effect of applying the RP via this mechanism has been determined.The effect of applying the RP through this mechanism has been identified.Table 17 depicts the influence of RP on the related quality characteristics.
The findings show that RP reduces understandability, reusability, functionality, and TQI by decreasing cohesion.

10) RENAME METHOD
The RM aims to make the name of the method explain its purpose.The RM is carried out by one mechanism (M1).The effect of applying the RM through this mechanism has been determined.The influence of RP on the associated quality characteristics is seen in Table 18.The results show that the RM does not affect either the internal or external qualities of the product.
The findings of this study provide valuable insights into the impact of various refactoring methods on software quality characteristics.One of the key findings is that the mechanisms for applying refactoring methods play a significant role in determining their effects on software quality.The study identified different mechanisms for each refactoring technique, depending on the internal design of the software system.This led to variations in the impact of refactoring methods on quality characteristics.Moreover, the study explored the impacts of each refactoring method through different mechanisms.The study's findings emphasize the importance of understanding the specific mechanisms and their effects when applying refactoring methods to improve software quality.By identifying the mechanisms and their corresponding impacts, software practitioners can make informed choices in selecting appropriate refactoring methods to address design defects and enhance quality characteristics effectively.The obtained results from this study are of significant importance in the field of software engineering and refactoring practices.They shed light on the complex relationship between refactoring methods and software quality characteristics, providing valuable insights and guidance for software developers, researchers, and industry experts.The results highlight the importance of understanding the mechanisms of applying refactoring methods and their corresponding impacts on quality characteristics.Armed with this knowledge, software developers can make informed decisions when selecting appropriate refactoring techniques to improve specific aspects of their software systems.This helps in addressing design defects and optimizing the software's overall quality.
As mentioned in the paper, maintenance and evolution activities consume a significant portion of software development costs.By knowing how different refactoring methods affect software quality, developers can focus on the most effective techniques to enhance reusability, flexibility, and extendibility.This, in turn, reduces maintenance efforts and costs in the long run.Understanding the various impacts of refactoring methods on quality attributes allows developers to assess potential risks associated with adopting specific techniques.They can choose refactoring methods that align with the project's goals and avoid those that might introduce undesirable consequences on software quality.
The findings contribute to the growing body of knowledge in the field of refactoring research.By identifying the mechanisms and impacts, this study provides a foundation for further investigations into the relationships between refactoring and software quality.Future research can build upon  these results to explore additional refactoring techniques or different software systems.Refactoring tools and automated code refactoring services can leverage these results to provide developers with more intelligent and context-aware suggestions.By understanding the mechanisms and their impacts, such tools can offer targeted and relevant refactoring recommendations, making the refactoring process more efficient and effective.
In conclusion, the obtained results have far-reaching implications for software developers and the broader software engineering community.They provide evidence-based insights into the relationship between refactoring methods and software quality characteristics, enabling informed decision-making, optimizing software maintenance, and advancing the field of refactoring research.By understanding the mechanisms and impacts of refactoring methods, developers can effectively improve software quality and reduce maintenance costs, ultimately leading to better software products and more efficient software development practices.

V. THREATS TO VALIDITY
A quality assessment model (QMOOD) [56] and the choice of refactoring approaches raise questions concerning construct validity.The top 10 refactoring methods in research and practice have been picked to avoid a subjective decision [13], [33], [40].This research also evaluated how refactoring methods affected the overall quality index (TQI), external characteristics, and internal quality characteristics using the acceptable quality model (QMOOD).The link between treatment and result poses a threat to the validity of the conclusion.Thus, 43 independent experiments were carried out across five case studies in this study.As a result, the study's findings are sufficient to form a conclusion.
Internal validity represents the degree to which research reliably demonstrates a cause-and-effect link between treatments and actual results 49.To examine the impact of refactoring methods via case studies, the case studies chosen for examination were evaluated solely in the scope of refactoring and had not been subjected to any treatments other than refactoring.The investigations began with small-scale case studies and moved on to larger case studies as they continued, enabling the researcher to acquire expertise.External validity is the capacity to generalize the results.Experiments have been conducted on a variety of open-source and academic case studies from different application fields and sizes to improve the external validity of this work.Because refactoring methods are often used in Java systems, this research examines their application in Java projects.The findings cannot, however, be said to be generalizable to other programming languages with varying refactoring methods and tool support.

VI. CONCLUSION AND FUTURE WORK
Refactoring is a popular strategy for increasing the quality of software products [18].Even though it has been demonstrated that refactoring does not improve all aspects of software quality indefinitely [16], [33], recent research indicates that different refactoring methods have noticeably different, sometimes contradictory, and negative effects on software quality [13], [19].As a result, developers face difficulties choosing appropriate refactoring methods to improve software quality [33], [39].No research has been conducted to explain why refactoring methods have contradictory effects on quality assurance or to optimize mechanisms for using refactoring methods.Therefore, this research offers an experimental investigation and in-depth analysis of the mechanisms of applying refactoring methods that result in various impacts of refactoring method application on quality characteristics.Ten refactoring methods were used one at a time in five case studies.The diverse effects of ten refactoring methods are produced in large part by the mechanisms of their application.Each of these refactorings makes use of a different mechanism, and each method affects quality characteristics differently (either positively, negatively, or not at all).To increase the quality of software applications, software engineers must choose the best mechanisms for every refactoring method.These results can serve as guidance for software engineers in utilizing refactoring methods to boost the quality of the software using the most effective mechanism, and they can also help software engineers understand how to utilize refactoring methods to enhance the quality of the software while considering this factor.In other words, these results help software professionals understand how to use refactoring methods to improve software quality while taking their mechanisms into account.
Future work will investigate the relationship between the mechanisms of applying the refactoring methods factor and other popular refactoring methods.Future empirical research might explore other factors, including developer programming skills, refactoring tools, quality measurement models, and software size.

TABLE 3 .
Statistics on metrics, quality characteristics, and TQI prior to applying refactoring methods.

TABLE 4 .
Statistics about refactoring methods utilized across the five case studies.

TABLE 5 .
The object-oriented measures after refactoring method (RM) implementation.

TABLE 7 .
A summary of every refactoring method's effect on metrics.

TABLE 7 .
(Continued.)A summary of every refactoring method's effect on metrics.

TABLE 8 .
A summary of every refactoring method's effect on external quality characteristics and TQI.

TABLE 9 .
Influence of add parameter.

TABLE 10 .
Influence of encapsulate field.

TABLE 11 .
Influence of extract class.

TABLE 12 .
Influence of extract superclass.

TABLE 13 .
Influence of hide method.

TABLE 14 .
Influence of inline class.

TABLE 15 .
Influence of inline method.

TABLE 16 .
Influence of move field.

TABLE 17 .
Influence of remove parameter.

TABLE 18 .
Influence of rename method.