Possible ways to refactor the code which had Java interface solely used to define lots of constants.. You can now imagine how this class is used to access these consts.
4 Answers
This is known as a constant interface anti-pattern. Although the previous link provides a way to fix this (using a class and static imports), I think there is a better way of refactoring this. Follow the suggestion here to fix this. Overall it is better to move the constants to the appropriate classes/abstractions rather than using one utility constant class. For e.g Calendar class defines only the constants that are relevant to its operations. Also as CoolBeans suggested try converting those String constants to enums where applicable.

- 78,777
- 46
- 231
- 327
-
I like this link. I will favorite it. – CoolBeans Jan 31 '11 at 06:00
-
1Huh - we both referenced each other. :) – CoolBeans Jan 31 '11 at 06:08
-
Legacy real world projects are a mess and priority always matters. Accordingly, refactoring or related automation meets the need. – John Jan 31 '11 at 08:25
Seems like a good usecase for enums. So take out the interface and replace it with an enum. Since it is a collection of constants enum fits the bill nicely. Moreover, enums are one of the most efficient ways to implement a Singleton in Java.
Instead of duplicating answers, take a look at these good relevant questions.
Alternatively as Pangea mentioned you can do static imports. I think both approaches are fine but enums in my opinion will be a better placeholder for organizing your unrelated constants in relevant meaningful groups.
-
1Sorry - you also said "otherwise" - "Any refactoring tips (or otherwise) that help automate the above changes?" . I think enums would be a more efficient and cleaner way to do this refactoring. – CoolBeans Jan 31 '11 at 05:59
So you have a big bag of constants (you don't say how big, but I've seen things like this with thousands of entries). Importing all of these values is a mess, as you get all the unrelated values imported into everything.
Rather than automating the changes, what I'd do is separate the constants into logically coherent groups, and then moving each group into the class hierarchy where they make sense. e.g. if you've got constants for COLOR_RED, COLOR_GREEN, DATE_FIELD, WEEK_FIELD, you'd probably want to appropriately split them into the color and data hierarchies. For the first pass ignore edge cases where you can't decide immediately - anything you can do to trim the constants down to coherent groups will help.

- 55,454
- 12
- 93
- 132
You could attack the source files with a shell script that does the following:
for all .java files:
if (content matches " class ? imports Singleton {"):
replace "imports Singleton" with ""
append "import static Singleton.*;\n" after package declaration
This is far from perfect (it just ignores cases where a class imports Singleton and other interfaces...) but it could be a practical strategy - and maybe it's OK to solve 80% with a quick script and correct the remaining 20% manually (IDE will report errors).

- 113,398
- 19
- 180
- 268