Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Need Assistance With Extensible Types for a Library  (Read 607 times)
0 Members and 1 Guest are viewing this topic.
Offline Aaron Goulet

Senior Newbie





« Posted 2013-07-29 00:49:20 »

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:

1  
2  
3  
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 <CommandSubClass>.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:

1  
2  
3  
4  
5  
6  
@Override
public void command(Command cmd) {
  if (cmd.getType() == Command.MovePlayerNorth) {
    /* Do stuff here. */
  }
}


Halp!
Offline Nate

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #1 - Posted 2013-07-29 05:03:49 »

Use inheritance.
1  
2  
3  
4  
5  
6  
7  
public class Command {
...
static public class MovePlayerNorth extends Command {
...
public void command(Command cmd) {
   if (cmd instanceof Command.MovePlayerNorth) {
...

Offline 65K
« Reply #2 - Posted 2013-07-29 05:04:04 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Aaron Goulet

Senior Newbie





« Reply #3 - Posted 2013-07-29 05:25:53 »

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:

1  
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?
Offline Danny02
« Reply #4 - Posted 2013-07-29 05:59:37 »

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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
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.
1  
KeyManager.addCommand(<???> commandType, int keyID, int keyEventType, new Listener{void do(){player.move(2,3);}});

Offline Aaron Goulet

Senior Newbie





« Reply #5 - Posted 2013-07-29 06:06:42 »

Thanks, Danny02 and everyone else, for the input. Smiley 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!
Offline Aaron Goulet

Senior Newbie





« Reply #6 - Posted 2013-07-29 07:55:27 »

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.

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!
Offline supaFool

Junior Devvie


Projects: 2



« Reply #7 - Posted 2013-08-05 03:36:58 »

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
Offline Jeremy
« Reply #8 - Posted 2013-08-05 05:05:57 »

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.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (40 views)
2014-12-09 22:41:13

BurntPizza (75 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (45 views)
2014-11-29 21:32:03

toopeicgaming1999 (113 views)
2014-11-26 15:22:04

toopeicgaming1999 (100 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!