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)
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.
Joined: Dec 12, 2002
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
Joined: Oct 02, 2003
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?
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 ]
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
Joined: Oct 02, 2003
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