Today I figured out an interface for having agents (individuals (models)) specify events in EcoGillespie. Each possible event will be, surprise surprise, an object.
I considered a few ways of structuring this object. The following were rejected for fairly obvious reasons:
- Specify events as
Methodobjects Seemed like the right approach at first, because then you can just directly implement events as methods in the class. But it’s ultimately a bad idea. Doing indirect method invocation using Java reflection is way, way slower than direct method calls. Event methods are going to be called all the time. Furthermore, I’d have to wrapMethodin anEventobject anyway, since you might want to specify arguments to the methods. - Use a string or int or enum The idea here is to just specify different events using some identifier that gets parsed out by a standard method implemented by the model. It’s basically indirect method calling, but faster, and uglier. Still indirect, though.
The structure I adopted is to represent events using inner classes. Each event is an instance of a subclass of Model.Event, which the model implementor will define as, e.g., MyModel.MyEvent. The event includes a rate (for use in the Gillespie algorithm) and one required method, perform(), which actually performs the event. Because Event is an inner class of Model, it can access members and methods of Model directly. So with just a few extra curly braces and so on, you get all the advantages of passing Method objects without the slowdown.
A modeler could decide to have just one Event subclass, and add member data to store the specifics of the event. Or if there are a few distinct types of events, each of which has very different behavior, there could be separate subclasses for each type, with different implementations of perform(). It doesn’t matter—all the framework cares about is the presence of the rate value and the perform() method.
Pretty slick, I think.