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.

4 comments
Comment actions Permalink

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:

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.




0
Comment actions Permalink

In article <288568632507611772634576@news.jetbrains.com>,
Keith Lea <keith@cs.oswego.edu> wrote:

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


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

0
Comment actions Permalink

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

0
Comment actions Permalink

In article <d59liu$prj$1@is.intellij.net>,
"Thomas Singer (MoTJ)" <I@HateSpam.de> wrote:

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


Yup. Pretty much. I thought I'd ask... like I said one never knows
what kind of magic JB has done.

R

0

Please sign in to leave a comment.