Models very quickly grow to have lots of actions with splits in a single sequence, and adding the logic for the Agents in the same place makes the sequence of actions hard to follow.
\nActions should be created by methods inside the agent the action is for. The methods should have clear names indicating what the actions purpose is so that the sequence of steps becomes a sequence of step names rather than a sequence of lots of hard to read code.
\nAn example of the Action being defined inside the Agent
\npublic class Flat extends Agent<GlobalState> {\n //Function sendVacancyMessage returns an Action \n public Action<Flat> sendVacancyMessage() {\n return Action.create(\n Flat.class,\n flat -> {\n if (!flat.isOccupied()) {\n flat.broadcastMessage(new Messages.Vacancy(flat.size));\n }\n });\n }\n} \n\n// The sequence calls the method instead of defining the logic.\npublic class myModel extends AgentBasedModel<GlobalState> {\n\n @Override\n public void step() {\n run(\n \tAction.create(Flat.sendVacancyMessage())\n );\n }\n} As can be seen below the code becomes easy to read because the steps are all defined inside the agents.
\nRunning a number of methods that return actions (Java)
\nrun(\n Split.create(\n Flat.sendVacancyMessage(),\n Household.bidIfHomeless(),\n Sequence.create(\n Household.giveUpFlat(),\n Flat.notifyBucketOfVacancy()\n ),\n Bucket.processBidsAndVacancies()\n ...\n );\n )Once the actions are all being defined inside the agent classes, as the agents grow and the number of methods being defined for the agents increases, there starts to be lots of duplication in the code that can be avoided.
\nTo avoid this, when an Agent class is created, it should be created with a static action method.
\nStatic method that returns an action (Java)
\npublic class Flat extends Agent<GlobalState> {\n // Static action method\n public static Action<Flat> action(SerializableConsumer<Flat> action) {\n return Action.create(Flat.class, action)\n }\n} This action method can now be used when creating the methods that return actions.
\n(Java)
\npublic class Flat extends Agent<GlobalState> {\n\n public static Action<Flat> action(SerializableConsumer<Flat> action) {\n return Action.create(Flat.class, action);\n }\n\n public Action<Flat> sendVacancyMessage() {\n return action(\n flat -> {\n if (!flat.isOccupied()) {\n flat.broadcastMessage(new Messages.Vacancy(flat.size));\n }\n });\n }\n} An alternative way of using this action method is from inside the Sequence, defining the methods that return actions as methods that can be called from inside the actions.
\n(Java)
\npublic class Flat extends Agent<GlobalState> {\n\n public static Action<Flat> action(SerializableConsumer<Flat> action) {\n return Action.create(Flat.class, action);\n }\n\n public void sendVacancyMessage() {\n if (!flat.isOccupied()) {\n flat.broadcastMessage(new Messages.Vacancy(flat.size));\n }\n }\n} \n\n// Use the static action method from inside the sequence\nrun(\n Split.create(\n Flat.action(Flat::sendVacancyMessage),\n ...\n )\n);When creating classes for the messages being sent, all message classes (used by the entire model) should be defined in a shared message class.
\nCreating them inside Agents, the Model or loose as their own separate class should be avoided.
\nCreating static nested message classes (Java)
\npublic class Messages {\n public static class Vacancy {\n public double size;\n public Vacancy(boolean size) {\n this.size = size;\n }\n }\n\n public static class Bid {\n public double deposit;\n public Bid(double deposit) {\n this.deposit = deposit;\n }\n }\n}If multiple agent types need to share some common functionality, while having their own unique functionality and uses, it may be helpful to introduce inheritance, in which a superclass is created to hold the shared functionality.
\nFor example, a Hotel and a Flat have some common functionality, but they also have some differences. Create an Accommodation class, for Hotel and Flat to extend. Accommodation can be used now when specifying an action for all Hotels and Flats.
\npublic class Accomodation extends Agent<GlobalState> {\n public int size;\n public Action<Accomodation> sendVacancyMessage() {\n return Action.create(\n Accomodation.class,\n accomodation -> {\n // if vacant, send message ...\n });\n }\n}\n\npublic class Flat extends Accomodation {\n\tpublic Action<Flat> registerNewHousehold() {\n return Action.create(\n Flat.class,\n flat -> {\n // new household registration ...\n });\n }\n} \n\npublic class Hotel extends Accomodation {\n\tpublic Action<Hotel> registerBooking() {\n return Action.create(\n Hotel.class,\n hotel -> {\n // new booking ...\n });\n }\n}\n\npublic class myModel extends AgentBasedModel<GlobalState> {\n\n @Override\n public void step() {\n run(\n // Some steps are for both Hotel and Flat\n Accomodation.sendVacancyMessage(),\n Household.requestHome(),\n Split.create(\n // Some steps are only for Hotel/Flat\n Flat.registerNewHousehold(),\n \tHotel.registerBooking()\n ) \n );\n }\n}Functionality, or methods that are not agent specific but are for general tasks that are needed by one or more agents or by the model shouldn't be placed together with the agents, but should be in a class of their own.
\nExamples of this may be a data loader that an agent might use to load data to spawn new agents with, or a distribution class which builds distributions based on some input/loaded data.
\nStatic methods should be created for these, so the methods can be accessed easily from anywhere in the model
\npublic class Distribution {\n public static EmpiricalDistribution loadDistribution(){\n // load distribution\n }\n}\n\npublic class Flat extends AgentAge {\n\tpublic Action<Flat> registerNewHousehold() {\n return Action.create(\n Flat.class,\n flat -> {\n EmpiricalDistribution distribution = Distribution.loadDistribution();\n // use distribution\n });\n }\n}