| Refactoring idea for org.eclipse.core.internal.runtime.InternalPlatform? [message #1413487] |
Thu, 28 August 2014 16:45  |
 Na Mising name
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 copse snippets in class org.eclipse.core.internal.runtime.InternalPlatform.java. In the class, there are three methods: getPreferencesService(), getContentTypeManager(), and getBundleAdmin(). I see these methods have pretty similar method bodies and also experience similar changes at least one time in the version history. Do you think it will be a good idea or bad idea to extract a method out of the methods while parameterizing any differences among them?
As far as I can see, these methods are only different in terms of types they use: IPreferencesService vs. IContentTypeManager vs. PackageAdmin. If you would like to apply the refactoring, what will be the refactored version like? Otherwise, 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.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03795 seconds
] 
Search
Help
Register
Login
Home
