Sign in to follow this  

Java enum

This topic is 3592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I don't understand what the problem is here with my use of enum. GAME_CONSTANTS.java
public interface GAME_CONSTANTS {
	
	// Directions Ships travel in
	enum Direction {NORTH, SOUTH, EAST, WEST};

Ship.java
// Movement methods
	public void move(Direction dir){
		switch(dir){
			case NORTH:
				if((coordinate.getY() - speed) >= 0)
					coordinate.moveY(-speed);
				break;
			case SOUTH:
				if((coordinate.getY() + speed + sprite.getHeight()) <= BACKGROUND_HEIGHT)
					coordinate.moveY(speed);
				break;
			case EAST:
				if((coordinate.getX() + speed + sprite.getWidth()) <= BACKGROUND_WIDTH)
					coordinate.moveX(speed);
				break;
			case WEST:
				if((coordinate.getX() - speed) >= 0)
					coordinate.moveX(-speed);
				break;
		}
	}

Game.java
// Read keyboard input
			if(leftPressed) 	playerShip.move(WEST);
			if(rightPressed)	playerShip.move(EAST);
			if(upPressed)		playerShip.move(NORTH);
			if(downPressed)		playerShip.move(SOUTH);

The error reads: WEST cannot be resolved Yes all the classes implement the GAME_CONSTANTS interface.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shakedown
Yes all the classes implement the GAME_CONSTANTS interface.

That's just horrible. Does saying "A ship is a game constants" make sense to you?

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Quote:
Original post by Shakedown
Yes all the classes implement the GAME_CONSTANTS interface.

That's just horrible. Does saying "A ship is a game constants" make sense to you?


That's common idiom for Java constants due to lack of namespaces. It saves typing while retaining correct values.

It is not a design, just a coding practice.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
That's common idiom for Java constants due to lack of namespaces. It saves typing while retaining correct values.

It's still hideous... at LEAST call the interfact GameConstantsConsumer, or GameObject or something. There should be some good way to organize your classes so that classes implement the interfaces they actually need and get the constants at the same time.

Furthermore, such abuses of OO constructs are even less excusable now, since static imports have been part of the language for some time.

Share this post


Link to post
Share on other sites
Quote:
Original post by smitty1276
Quote:
Original post by Antheus
That's common idiom for Java constants due to lack of namespaces. It saves typing while retaining correct values.

It's still hideous... at LEAST call the interfact GameConstantsConsumer, or GameObject or something. There should be some good way to organize your classes so that classes implement the interfaces they actually need and get the constants at the same time.

Furthermore, such abuses of OO constructs are even less excusable now, since static imports have been part of the language for some time.


Yes, sadly Java community has too much momentum.

Anyway, back to real problem:
if(leftPressed) 	playerShip.move(Direction.WEST);
if(rightPressed) playerShip.move(Direction.EAST);
if(upPressed) playerShip.move(Direction.NORTH);
if(downPressed) playerShip.move(Direction.SOUTH);


Ironically, your problem stems exactly from the above abuse of interfaces to save typing, something which isn't needed since enum keyword was added.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Anyway, back to real problem:

if(leftPressed) playerShip.move(Direction.WEST);
if(rightPressed) playerShip.move(Direction.EAST);
if(upPressed) playerShip.move(Direction.NORTH);
if(downPressed) playerShip.move(Direction.SOUTH);


Thank you. I thought I tried this, but it works fine now. I looked online in several different places for uses of enums, but somehow none of them used them across multiple files.

Quote:
Original post by greggles
Instead of inheriting from an interface, you should probably use static imports.

Greggles


Is this a common convention to access important globals all throughout your program, as opposed to implementing a constants interface?

Share this post


Link to post
Share on other sites
I declare my constants in a static class with its variables public but final. If things get complicated, get-methods can return related stuff that is just a few conversions away. Hence, I can access it from everywhere without passing around anything.

I have never talked to anyone about this, though. There might be reasons against it that I don't know ...

Share this post


Link to post
Share on other sites
You don't get around globals in this instance. This is the reason enums were added in Java 5. Many, many APIs define constants that are used as flags or settings. Most likely, DevFred was referring to global variables. These, of course, should always be avoided due to various issues, one of them being thread synchronization.
Also, to your question as to whether it's normal to import static things, yes, it is normal. It's very handy, but be wary of it, as it can lead to confusion sometimes. Especially with regards to scope.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shakedown
Quote:
Original post by DevFred
A common convention is to avoid globals like the pest.

That's a worthless response. How do you get around using globals?

By using a pure object oriented design.

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Quote:
Original post by Shakedown
Quote:
Original post by DevFred
A common convention is to avoid globals like the pest.

That's a worthless response. How do you get around using globals?

By using a pure object oriented design.


Won't that have it's downfalls as well? Will they be worth not having to use globals?

Share this post


Link to post
Share on other sites
Depends on what you mean by globals. Stuff like enums is perfectly harmless (they're just constants, nothing wrong with that), but global mutable state is generally nasty, for a lot of reasons. Thread safety is just one of them.

And no, there aren't really any downfalls to avoiding that. All variables (all mutable state) should be local. If other functions (and other threads especially) can access it, you're just asking for trouble, and it's usually a sign of bad design as well)

It's not even a question of "object oriented" or not. Functional programming is *much* more fanatical about avoiding global state, for example. It's just a sensible programming practice, as simple as that. If a bit of code needs to access a variable, pass it to the function. (Or keep it as a class member variable, depending on circumstances)

Globals aren't bad as long as they're immutable. If they're read-only (constants, flags, settings), that's fine, they're harmless, and if they're write-only (a log, for example, or anything else that doesn't impact the rest of the code), they're *probably* ok too. But anything you both read to and write to... has no place being a global. Keep it local so you can control who accesses it, and when.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Functional programming is *much* more fanatical about avoiding global state

Does functional programming even have the concept of state?

Share this post


Link to post
Share on other sites
Yes, functional programming does have a concept of state. However, instead of representing state changes by altering a mutable entity (as imperative-style programming does), it represents them by creating a new immutable entity which represents the new state.

OCaml (among others) cleanly contrasts imperative programming with functional programming, for instance when computing the sum of a list:

(* Using mutable state representation: 'acc' is the state *)
let acc = ref 0 in
List.iter (fun i -> acc := !acc + i) list;
!acc;

(* Using non-mutable state representation: 'acc' is the state again *)
List.fold_left (fun acc i -> acc + i) 0 list

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Quote:
Original post by Shakedown
Quote:
Original post by DevFred
A common convention is to avoid globals like the pest.

That's a worthless response. How do you get around using globals?

By using a pure object oriented design.


But, any reasonably complicated program is going to have a bunch of values that:

- only have one value for the entire scope of the application
- need to be accessed in disparate locations across the source code

You can call them whatever you want, but they are essentially globals. You could try to hide their global-ness by passing them around as member variables, but that's just a lot of busywork when you're dealing with pieces of data that really are destined to be global.

Share this post


Link to post
Share on other sites

This topic is 3592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this