views:

80

answers:

4

This seems like it should be fairly straight-forward, but I can't see anything obvious. What I basically want to do it to point at a method and refactor->extract class. This would take the method in question to a new class with that method as top level public API. The refactoring would also drag any required methods and variables along with it to the new class, deleting them from the old class if nothing else in the old class is using it.

This is a repetitive task I often encounter when refactoring legacy code. Anyway, I'm currently using Eclipse 3.0.2, but would still be interested in the answer if its available in a more recent version of eclipse. Thanks!

+5  A: 

I don't think this kind of refactoring exists yet.

Bug 225716 has been log for that kind of feature (since early 2008).
Bug 312347 would also be a good implementation of such a refactoring.

"Create a new class and move the relevant fields and methods from the old class into the new class."

I mention a workaround in this SO answer.

VonC
+1 for the bug references. Hope they get around to implementing one of them soon. Bug 312347, especially, provides a good argument for this feature.
Chris Knight
+1  A: 

Have you tried the Move feature of the Refactor group ? You can create a helper class and move there anything you want.

thelost
Hmm, maybe this works better with later versions of eclipse, but I'm only getting random types sourced from variables as receiving types of my Move method. thanks for the suggestion though.
Chris Knight
+1  A: 

This seems like it should be fairly straight-forward...

Actually, Extract Class is one of the more difficult refactorings. Even in your simple example of moving a single method and its dependencies, there are possible complications:

  1. If the moved method might be used in code you don't know about, you need to have a proxy method in the original class that will delegate to (call) the moved method. (If your application is self-contained or if you know all the clients of the moved method, then the refactoring code could update the calling code.)
  2. If the moved method is part of an interface or if the moved method is inherited, then you will also need to have a "proxy method".
  3. Your method may call a private method/field that some other method calls. You need to choose a class for the called member (maybe in the class that uses it the most). You will need to change access from "private" to something more general.
  4. Depending on how much the original class and the extracted class need to know about each other, one or both may need to have fields initialized that point to the other.
  5. Etc.

This is why I encourage everybody to vote for bug 312347 to get fixed.

kc2001
Great points. With regards to points 1 and 2, these apply to non-private methods, whereas I'm mostly looking for private extract class refactoring (which I would expect to be the usual case?). I also hadn't thought of the challenges of refactoring private methods which have lots of side effects. That would be a can of worms!
Chris Knight