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 Apr 25 '16 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\$ – Gad Wissberg Apr 25 '16 at 7:09

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() { ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.