Need Assistance With Extensible Types for a Library

Newbie & Debugging Questions
#1

I am currently writing a simple game library for personal use, and I’m having a massive brain fart on this one non-specific Java coding/OOP thing… Suppose I have an interface like this:


public interface Commandable {
  public void command(Command cmd);
}

Assume that the Command class has only one field for now, which is “type”. Let’s say that, using my library, I write a Player class that implements Commandable. What I want is to be able to EXTEND Command to add new types at a later date, so .getType() can theoretically return a different set of “type” values than the Command superclass.

I wanted to use Enums, but since they are static and final, they make poor candidates. standard ints WORK, but generally speaking I try to avoid representing a type as an int whenever possible. The end goal is I want to be able to do something like this in the Player class:


@Override
public void command(Command cmd) {
  if (cmd.getType() == Command.MovePlayerNorth) {
    /* Do stuff here. */
  }
}

Halp!

#2

Use inheritance.


public class Command {
...
static public class MovePlayerNorth extends Command {
...
public void command(Command cmd) {
   if (cmd instanceof Command.MovePlayerNorth) {
...
#3

The question is, what is the use case for your own types.
Such type based conditions are not OOP - take a look on the command design pattern instead.

#4

Honestly, I don’t have any library-level case uses; the plan was to set up a system where a generic ‘Command’ could be generated by, say, an input/network manager, and sent to the target object. The manager would know how to send what Command where by way of keeping a list of possible commands and targets, adjustable at runtime:


KeyManager.addCommand(<???> commandType, int keyID, int keyEventType, Commandable target);

Any time someone triggers the appropriate KEY_DOWN/KEY_UP event for the corresponding key, it sends the Command designated by commandType to the provided Commandable object. The implementation of the target object’s response to the command is completely modular.

With regards to Nate’s suggestion of using instanceof, I recall reading a while back that instanceof should be avoided, though whether that was due to performance issues or because it’s generally a bad habit, I can’t remember. This was a looong time ago, however, so that may not be the case anymore?

#5

The thing is this, if you want to be able to send any command to a any kind of object, there is no way around type casting or a huge static command-list(int constants). This would be some kind of an actor-system(like the Akka library).

You could do things a bit more typesafe if you give the Command interface a type parameter and an excecute method, like:


public interface Command<T>
{
  public void execute(T onThis);
}

//i.e.

public class PlayerMoveCommand implements Command<Player>
{
  private final int x,y;
  public PlayerMoveCommand(int xx, int yy){x = xx; y= yy;}
  public void execute(Player player){
    player.move(x,y);
 }
}

With this you would nicely encapsulate the command logic. No need to store all possible command logic in the Player class.

It would be hard on the other hand to store this kind of Commands in something like your KeyManager, because I guess this manager can hold any kind of Command. And because of this you would loose your needed type information.

Maybe it is better to throw this hole command-structure out of the window and just use listeners in the KeyManager which directly execute logic.



KeyManager.addCommand(<???> commandType, int keyID, int keyEventType, new Listener{void do(){player.move(2,3);}});
#6

Thanks, Danny02 and everyone else, for the input. :slight_smile: I’ve got a couple of ideas I’m bouncing around, but mainly I’m starting to come to the conclusion that I am making this thing a little too specific for a library. Ideally I should be programming the input specifics when I’m working on the actual game.

At the very least, the graphics side of things is coming along nicely!

#7

Actually, I take it back. Googled command design patterns, and found one that works perfectly for my library! Thanks for that, 65K; turns out I was looking at it wrong and just needed to learn something new!

#8

can’t you just make a class, and put a bunch of variables in it that are static, and refer to them…I didn’t really understand the question…lol

#9

Trying to use enums (or classes) here isn’t that great of an idea because it abstracts the function of that command into an object that shouldn’t be handling it.

The easiest solution, really, is just to use a string. Have an interface IInteractable

public String[] getCommands();
public void doCommand(String sCommand);

Then you have have a UI component (or any component) query and issue commands without knowing anything about the object. Further, the actual handling of the command is in the object and that allows you to make accessible commands (and the way they perform) context sensitive.

This sort of interface makes sense, because it is precisely the same interface you would provide to any human user.