Subject: | |
From: | |
Reply To: | |
Date: | Thu, 15 Mar 2018 15:28:52 +0000 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
I don't have a question about how to use some part of mason, but I am rather curious about the reasoning behind the architecture of the interface Steppable.
Why was the method step(SimState state) designed to take a parameter?
If my agents directly implement the interface Steppable, my agents have access to all other objects in my simulation which makes my agents hard to unit-test (since I have to initialize the 'god-object' SimState to call the step-method).
I am aware that I can circumvent this by creating a Steppable as described in the manual on page 109:
Steppable even = new Steppable() { public void step(SimState state) { myObject2.foo(); }};
But isn't this a little bit ugly from a design perspective, because the parameter state is completely ignored by myObject2.foo()?
I am also aware that I can use the sim.engine.MethodStep-method to avoid passing the SimState, but the manual does not recommend it for good reasons.
The manual also mentions that the Repast-method for stepping agents works like the sim.engine.MethodStep-method from Mason, but I recently looked into the current version of Repast Simphony 2.5 and Repast uses costume annotations @ScheduledMethod(start = 1, interval = 1), to add methods to the schedule, which seems to me that this is not a violation of Java contracts (as the mason manual claims on page 108). Is the mason manual maybe outdated or am I not correctly understanding the critique about the way Repast schedules methods?
|
|
|