Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Refactoring idea for org.eclipse.compare.CompareEditorInput?
Refactoring idea for org.eclipse.compare.CompareEditorInput? [message #1413482] Thu, 28 August 2014 16:32
Na Mising name is currently offline Na Mising nameFriend
Messages: 11
Registered: August 2011
Junior Member
Hi,

I'm doing some research in automatic refactoring suggestion. By observing the co-change pattern of some similar code, we would like to develop a tool to suggest possible refactorings to apply in order to extract out common code while parameterizing any difference between them.

I have examined the code snippets in class org.eclipse.compare.CompareEditorInput.java. In the class, there are two methods addCompareInputChangeListener(ICompareInput, ICompareInputChangeListener) and removeCompareInputChangeListener(ICompareInput, ICompareInputChangeListener). I see these two methods have pretty similar method bodies and also experience similar changes at least twice in the version history. Do you think it will be a good idea or bad idea to extract a method out of the two methods while parameterizing any differences between them?

As far as I can see, these two methods are only different in terms of one method call, fContainer.addCompareInputChangeListener(input, listener) vs. fContainer.removeCompareInputChangeListener(input, listener). If you would like to apply the refactoring, what will be the refactored version like? Will it be something like the following?

public abstract class TemplateClass{
public void extractMethod(...){
... ...
m0(fContainer, input, listener);
... ...
}
public abstract void m0(ICompareContainer fContainer, ICompareInput input, ICompareInputChangeListener listener);
}

public class TemplateClass1 extends TemplateClass{
public void m0(...){
fContainer.removeCompareInputChangeListener(...);
}
}
public class TemplateClass2 extends TemplateClass{
public void m0(...){
fContainer.addCompareInputChangeListener(...);
}
}
public void removeCompareInputChangeListener(...){
new TemplateClass0().extractMethod(...);
}
public void addCompareInputChangeListener(...){
new TemplateClass1().extractMethod(...);
}

If you don't like the refactoring idea, would you like to share the factors in your mind which affects your decision, such as complexity of refactoring, poor readability, poor maintainability, code size, etc. For each factor, how do you think it can affects your decision about using refactoring? If possible, any quantative analysis will be great. For example, if the code size after refactoring is greater than that before refactoring, I won't do refactoring. Or
if there are only two lines shared between two code snippets, I won't do refactoring, etc.

Thanks a lot for your help! Your suggestion will be very valuable for our research.
Previous Topic:Customize EMF compare - Match phase.
Next Topic:EMF compare
Goto Forum:
  


Current Time: Wed Apr 24 14:11:02 GMT 2024

Powered by FUDForum. Page generated in 0.03035 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top