I could do it much simpler with Reflection. Should I?

Question

So I'm writing a game and I've come across a conundrum where I believe Reflection might be a better solution. But knowing that Reflection is discouraged and my other solution doesn't look that pretty, I thought I'd ask here and see what's actually a better idea in this scenario.

Essentially I've got an abstract card class, and will have several implementations of it. I have a case where I'm given a card name and need to construct an object of it, just given the name.

I know I could use either:

a) Reflection and use forName and invoke. It'll be very short code, scale well, and easy enough to write. That said, it's Reflection, and I'm all for avoiding it when I don't particularly need it.

b) Use a Factory design pattern and then have a giant conditional check, calling the appropriate class based on the name I supply. It's not difficult to write but requires constant maintenance and will take a while to write, plus it won't scale well. That said, it's a non-Reflection solution.

So what is the ideal solution? Do I just use Reflection because it keeps my code nice and short?

Answer 1

Here's an alternative (not sure if it's the "ideal solution" like you've mentioned, but I think it's worth considering): enumerated types. It will still be a huge list, but maybe a bit cleaner? And you have to define them all somewhere.

An example of what I mean:

enum CardType {
  CARD_ONE(new Card(arg0, arg1, arg2, ..., argN)),
  CARD_TWO(new Card(arg0, arg1, arg2, ..., argN)),

  ...

  CARD_N(new Card(arg0, arg1, arg2, ..., argN));

  private final Card card;

  private CardType(Card card) {
    this.card = card;
  }

  public Card getCard() {
    return card;
  }
}

Then when you need to get one by name, just do:

public Card getCardByName(String cardName) {
  return CardType.valueOf(cardName).getCard();
}

This assumes the cards are singletons, but you could just as easily make the getCard method do some sort of factory logic to create a new one.

Answer 2

I would suggest to use a factory pattern and use a prebuilt factory like Spring that you can use to define bean instances with there rather then implement your own factory. It will scale easier as you can just define more bean types in either XML or annotated Java code. Just make sure you use non-singleton beans and every time you ask your spring factory for a bean of a name it will call the constructor properly. It will even allow you to do dependency injection at the same time for free.