I'm making a game for Android using Libgdx with Android Studio in Java. In my game, I have a class called ObjectFactory which has a method createGameObject(int objectType) which receives an integer from ObjectIds (a static class that hold a final static numbers for every object type: PLAYER = 0, BULLET = 1, ENEMY = 2 and etc...).

This method has a switch condition and 'till now I have reached 69 types of objects. The method gets the id, looks for it using the switch, creating that object and returns it. At the beginning it was comfortable using this way, but now it's really annoying looking for stuff over there because the switch statement is huge. This is an example of a case:

        case Rules.GameObjectIds.EXPLOSION:
            Explosion explosion = Pools.obtain(Explosion.class);
            explosion.init(getTextureAtlas(explosion, AssetsPaths.Gfx.Sheets.Misc.Explosion.DATA_FILE), AssetsPaths.Gfx.Sheets.ImagesNames.BIG_EXP, x, y, AssetsPaths.Configs.ParticleEffects.EXPLOSION);
            gameObject = explosion;
            listName = Rules.System.GameObjectTypes.EXPLOSIONS;
            createEffect(AssetsPaths.Configs.ParticleEffects.BLAST_RING, gameObject);

I'm thinking about a way to simplify the Object Factory, any suggestions? Thanks in advance

  • 1
    \$\begingroup\$ What kind of work is involved inside each switch case? Is any of it suitable to be made data-driven so you don't need to be spell out every combination in code? \$\endgroup\$
    – DMGregory
    Commented Apr 25, 2016 at 0:32
  • \$\begingroup\$ Well, I need to do a specific work in every case. I've added an example of a case in the original post. Using data-driven sounds good, how should I implement these pieces of code in external data files? \$\endgroup\$ Commented Apr 25, 2016 at 7:09

1 Answer 1


The nice thing about the Factory pattern is that the base class can be abstract and you can have different derived Factory classes.

That means you can have an ExplosionFactory, a BulletFactory, an EnemyFactory and so on, which all inherit from the basic class GameObjectFactory. Any code which is common to all objects would be in the GameObjectFactory while the derived classes only do what's unique to that particular object type and call a method from the base-class to do the rest.

An abstract base-class doesn't need to know anything about the classes derived from it. So when you want to add a new factory, you don't need to edit the base-class at all. You could even ditch that Rules.GameObjectIds enum.

When you want to create an object of the specific type, you just get an instance of a factory of the desired type.

You can also make your factories type-safe by declaring the GameObjectFactory as a generic class and the derived class as an extensions with a more specific type:

public abstract class GameObjectFactory<T extends GameObject> {

     public T createGameObject() { ...

public class ExplosionFactory extends GameObjectFactory<Explosion> {

     public Explosion createGameObject() { ...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .