Managing a MongoDB deployment? Take a load off and live migrate to MongoDB Atlas, the official automated service, with little to no downtime.

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();

and:

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:

Some Tips for Refactoring

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.

MongoDB Atlas is the easiest way to run the fastest-growing database for modern applications — no installation, setup, or configuration required. Easily live migrate an existing workload or start with 512MB of storage for free.