MASON-INTEREST-L Archives

March 2018

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Simon Sohrt <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 15 Mar 2018 15:28:52 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (13 lines)
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?

ATOM RSS1 RSS2