Refactoring static members?
I'm going through some refactoring of old swing code... in the code
there is code like this:
public class Foo {
private static final JDialog dialog = new JDialog();
...
}
Then everything uses the dialog instance. I think that's just not cool,
and would like to make my life easy by clicking on dialog and choosing a
refactoring to make it non static, but have idea cascade the changes...
I suspect that's rather tough to do considering what would be involved
in doing that... but I've seen incredibly complex things from JetBrains,
and was wondering if something existed and I'm just not seeing it.
Thanks
R
ps. this would be better if I can do in 4.5.x since I trust it, but if
Irida is the only choice, that's fine as well.
Please sign in to leave a comment.
I don't understand what you want. Couldn't you make it nonstatic by removing
"static"? I assume you want something more complex, so I'll show you a general
refactoring series I do when I want to change fields.
1. Encapsulate fields - encapsulates the field into static accessors (getter
& setter) so only those two methods reference the field itself
2. Change what's in the getter & setter methods
3. Inline the getter & setter methods
This is a way of replacing all reads and writes of the variable with some
custom code. Maybe this is what you want.
I would do it like this:
In article <288568632507611772634576@news.jetbrains.com>,
Keith Lea <keith@cs.oswego.edu> wrote:
I guess I didn't explain fully. Note that the variable is also final,
so no setter there for sure, unless the instantiation is also removed.
What I would like to do is remove the static from the member variable,
as well as not instantiate it there. Further since the rest of the
methods which are making use of this variable are also static, the
change needs to take that into account. So never mind, because I think
I have to do it manually and painfully, one step at a time, until I
change all of them and reconstruct the code properly.
Thanks
R
Robert, I think, your refactoring is not that trivial, that IDEA can handle
it automatically. I would got this way:
1) search for usages of the dialog,
2) in methods where it is used, pass it as parameter,
3) repeat step (2) until you only have a few references, where you want it
to be created,
4) encapsulate the field access (aka, create a getter),
5) change the getter to create a new dialog on each invocation,
6) inline the getter.
Tom
In article <d59liu$prj$1@is.intellij.net>,
"Thomas Singer (MoTJ)" <I@HateSpam.de> wrote:
Yup. Pretty much. I thought I'd ask... like I said one never knows
what kind of magic JB has done.
R