Over a million developers have joined DZone.

Refactoring Java in IntelliJ

DZone 's Guide to

Refactoring Java in IntelliJ

Remember, it's never too late to refactor. Do it in small chunks. Protected your code with tests. And whenever possible, let your IDE do the work for you.

· Java Zone ·
Free Resource

As my RestMud game grew, I noticed that I do have a fair bit of unit testing, but I also perform more integration testing than unit testing.

The good thing about this approach is that the integration testing represents requirements: In this game, I should be able to do X, and my integration tests at the game engine level create test games and check conditions in there.

These tests rarely have to change when I amend my code.

The side effect of this type of testing is that the classes don’t have to be particularly good, so I have a lot of large classes and no particularly good organization.

I’m now refactoring the classes and organizing the code to have four main sections:

  • Game Engine
  • Games
  • API
  • GUI

At the moment, I’m concentrating on the Game Engine.

I have a large main class called MudGame, and I’m splitting that into smaller classes now.

Refactoring From Map to POJO

As an example, my MudGame used to have a Map for locations, and collectibles, and messages.

This meant that I had four or five methods for each of these collections in my MudGame. Meanwhile, I now have only a few high-level methods in Game, and most of the code has moved to the Locations or Collections objects.

As I was doing this, I had to make a decision. Do I make a public final field, or do I create a private field with an accessor method.

I initially chose public final and amended the code, and then changed my mind to have an accessor method.

I don’t worry too much about this because it is easy to use IntelliJ refactoring to rename and wrap fields in accessor methods.

private Map<String, MudLocation> locations = new HashMap<>();

To an object that manages locations, which contains all the code methods that were on MudGame:

public final Locations gameLocations = new Locations();

I chose to make the field public initially, then I refactored using “Encapsulate as Method”:

private final Locations gameLocations = new Locations();


    public Locations getGameLocations() {
        return gameLocations;

Refactoring Methods to Inline Code

Sometimes, when I have a method that is small and doesn’t really add any value because I delegate all the functionality off to another Object, I might choose to inline it:

    public MudLocationObject getLocationObject(String nounPhrase) {
        return getLocationObjects().get(nounPhrase);

When I inline this, then anywhere in the code that had:

MudLocationObject locationObject = game.getLocationObject(thingId);


MudLocationObject locationObject = game.getLocationObjects().get(thingId);

Some Tips for Refactoring

  • Requirement level tests should not have to change during refactoring.
  • Make sure you have tests before you refactor.
  • Don’t worry too much about naming or field/method choices during initial coding because it is easy to refactor later.
  • Use IDE refactoring where possible.
  • When code gets ugly, get refactoring.
  • Refactor in small chunks, keep chipping away.
  • Refactor low hanging fruit first as it makes it easy to see what comes next.
  • Group code together to loosely organize prior to refactoring into new classes.
  • Refactor classes to represent semantics as well as helping organizing code.

It’s never too late to refactor your code.

java ,intellij ,refactoring ,legacy applications ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}