New refactoring: Reduce visibility

Maybe it's not a refactoring, but still...

I have a non-private field in a class. I believe that the
field can be made private. How do I that, and make sure
that I don't break anything?

a) Type 'private' and recompile.
b) Find Usages and check for usages from other classes.
c) Use Encapsulate Field.

Alternative a seems crude, and I may have other compile
errors from code-in-progress that I don't want to deal
with right now.

Alternative b verifies that I won't break anything, but
it feels long-winded and forces me to do manually what
could be automated.

Alternative c is inappropriate since I'm not interested
in providing accessors. I believe the field is private
and I don't want to provide access to it.

Is there an alternative d that I'm missing? If not, I'm
proposing a new refactoring/intention: Reduce visibility.
This refactoring should allow me to quickly, using a dialog,
propose a new visibility, say 'private', and have that
visibility verified and applied. If the new visibility is
not valid, I want that reported with a list of usages and
the options to cancel, provide accessors, or ignore uses
and continue.

It's a lot like Change Signature, and it could perhaps
reuse that name.

Tell me if I've missed something obvious. Otherwise I'll
add a JIRA item.

/Mikael

3 comments
Comment actions Permalink

AFAIK there's an inspection that suggests access can be weaker

0
Comment actions Permalink

True, but it's only available for offline inspection.

0
Comment actions Permalink

Mikael Karlsson wrote:

Is there an alternative d that I'm missing? If not, I'm
proposing a new refactoring/intention: Reduce visibility.
This refactoring should allow me to quickly, using a dialog,
propose a new visibility, say 'private', and have that
visibility verified and applied. If the new visibility is
not valid, I want that reported with a list of usages and
the options to cancel, provide accessors, or ignore uses
and continue.

+100

0

Please sign in to leave a comment.