wood burning stoves 2.0*
The moose likes Java in General and the fly likes game Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "game" Watch "game" New topic
Author

game

Matt Buckley
Greenhorn

Joined: Oct 02, 2003
Posts: 3
hi i'm trying to make a game. the game will
be played by computer agent objects.
Agents are stored within the environment class.
a server class will iterate through the agent objects (obs)
in the environment (env) and execute their next move.
i have 3 general approaches (could anybody
suggest which is the best/will work...
Approach 1 (Get List)

Approach 2 (Get Iterator)

Approach 3 (Inner Class)

thanks
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
3 doesn't seem like much of an option as the server is likely to reasonable complicated and that's not good for an inner class.
1 & 2 are similar. The Law of Demeter would suggest that 2 is the best choice out of these.
D.
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
BTW. What does the Env class do ?
It sounds like it may be an area where you store global variables. If so, this a bad idea
Matt Buckley
Greenhorn

Joined: Oct 02, 2003
Posts: 3
Originally posted by Don Kiddick:
BTW. What does the Env class do ?
It sounds like it may be an area where you store global variables. If so, this a bad idea

the Environment class stores an ArrayList,
the ArrayList holds all the agent objects.
the Environment class also stores a list of
static objects.
my idea was for the server to access the environment
and manipulate it, and also agents can manipulate the
the environent.
is this is bad idea, is there a better more robust structure?
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
my idea was for the server to access the environment
and manipulate it, and also agents can manipulate the
the environent.

The Matrix?
is this is bad idea, is there a better more robust structure?
Well, here is a general idea. Your classes should be designed with high cohesion and low coupling. High cohesion means that a class has a well defined, narrow set of responsibilities. Low coupling means that a class doesn't have a lot of dependencies on other classes.
In your case, the fact that both server and agents can manipulate the environment doesn't mean that any of these classes need to contain (or even have a reference to) another class. If they do, you may be coupling them forever, and each time you make a change to one of them, you would also need to change the other ones.
Ideally, your enviroment, server, and agent classes should know as little as possible about the existance of each other. This could be accomplished by introducing another class that would act as a controller or a mediator. So, if your server needs to manipulate the environment, it would signal the intent to the controller/mediator, which will do the job. This is, of course, just one possible way to design it, and there are many other alternatives. However, high cohesion and low coupling unite all the good designs in their intent to make the code easy to understand, change, and maintain.
[ October 02, 2003: Message edited by: Eugene Kononov ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Of the original choices (focusing just on the List/Iterator handling, not other organizational questions), I'd strongly recommend 1. (Except return a List rather tha ArrayList for generality.) The collections framework is generally designed to work with Collection instances (especially List instances) rather than Iterators, up to but not including the point where you actually do the iteration. That is, there are a bunch of potentially useful methods floating around, like
Collections.copy(List, List)
Collections.sort(List)
Collections.unmodifiableList(List)
new ArrayList(Collection)
new TreeSet(Collection)
and many more. If you have a method which returns an Iterator, it's harder to apply any of these other methods to the result. But if you return a List (or Set or whatever interface is more appropriate) you will have easy access to the rest of the collections framework, should hte need arise. The Law of Demeter notwithstanding, any programmer who expects to use an Iterator at all should know how to get that Iterator from a Collection in a single method call. It's easy to convert a Collection to an Iterator; it's more work to go the other way. So keeping the Collection as a Collection as long as possible will maximize the reusability of your code.
To iterate through any Collection:

Calling iterator() immediately before iterating is standard usage; you don't need to do it previously in a separate method. The Iterator isn't useful for anything else anyway, you might as well discard it immediately when you're done, and using a local variable for this makes sense.
Note also that upcoming JDK 1.5 is supposed to have a new construct for iterating throuch a collection more gracefully:

This new construct is designed to work with any Collection, Iterator, or array. So there's no need to convert to an Iterator before hand; the compiler will handle it for you. This may not help you much right now, butit reenforces the idea that passing around Collections rather than Iterators is standard usage.


"I'm not back." - Bill Harding, Twister
Matt Buckley
Greenhorn

Joined: Oct 02, 2003
Posts: 3
ok,
i think my current design is definitely high coupling.
1. my agent object carries a reference to the environment
(the reason the agents have refs to the environment is
because they need to access it methods)
&
2. my environment object's arraylist has references to agents.
this is what i'm guessing could be done...
>controller class has a reference to the environment.
>would the server and agents then have references to
the controller?
thanks
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: game
 
Similar Threads
LinkedList and remove
Collection Error
Implementation for Iterator interface ?
Q about ArrayList/LinkedList
TreeXxx VS PriorityQueue