{"data":{"markdownRemark":{"html":"

Actions and Sequences

\n

Models can quickly grow to have many actions with splits in a single sequence. Adding the implementation logic for agents in the same place can make the sequence of actions hard to follow.

\n

Actions should be created by functions inside agents. The functions should have clear names indicating the action's purpose. With purposeful naming, the sequence of steps becomes a sequence of clear action names, rather than a sequence of code that is hard to read.

\n

If the function which creates an action is static, that function should return the action it creates.

\n

The easiest way to build an action-creating function is to put all the implementation in a static function, then call that static function inside a model step.

\n
// Static function which creates an action that sends a message.\npublic static Action<Flat> sendVacancyMessage() {\n    return Action.create(\n        Flat.class,\n        flat -> {\n            if (!flat.isOccupied()) {\n                flat.getLinks(Links.VacancyLink).send(Messages.Vacancy.class, flat.size)\n            }\n        };\n    );\n}\n\n// Agent-based model that uses the static action to send a message.\npublic class myModel extends AgentBasedModel<GlobalState> {\n    @Override\n    public void step() {\n        run(\n            Flat.sendVacancyMessage()\n        );\n    }\n}
\n

Action-creating functions built in this way can be placed into sequences and splits, while ensuring that overall functionality is still clear.

\n
run(\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);
\n

When many action-creating functions are built statically though, two different problems can happen. The first problem is that there may be a lot of duplicated code inside the static function, which can cause maintenance problems. The second problem is that creating a lot of static functions may violate encapsulation principles. Static functions are usually best reserved for utility functions, rather than specific functionality in an object. There is really no need to expose all the functionality of the sendVacancyMessage function.

\n

These problems can be solved by implementing a static function inside the agent which creates actions, regardless of what those actions are. A generic function like this keeps all the unique functionality of the sendVacancyMessage function as part of the agent, where it belongs. The sendVacancyMessage function still returns an action. The static action-creating function can then be used throughout the agent, as many times as necessary, without impacting other functions or duplicating code.

\n
public class Flat extends Agent<GlobalState> {\n\n    // Generic static action-creating function.\n    public static Action<Flat> action(SerializableConsumer<Flat> action) {\n        return Action.create(Flat.class, action);\n    }\n\n    // Vacancy message function which calls the action creator.\n    public Action<Flat> sendVacancyMessage() {\n        return action(\n           flat -> {\n               if(!flat.isOccupied()) {\n                   flat.getLinks(Links.VacancyLink).send(Messages.Vacancy.class, flat.size);\n               }\n           };\n        });\n    }\n}
\n

These functions are organized much better, but there is still more refining that can be done. When specific agent functions return actions, as in the previous example, it is always necessary to explicitly call the action creator, and usually an object initializer. These lines inside the agent functions do not actually have anything to do with what the function does; they are just coding glue for the action creator.

\n

To get rid of this coding glue, implement agent functions that do not return anything. This ensures that they contain only the code necessary to perform their jobs, nothing else. These agent functions can then be called using the generic action creator function. Structuring functions and calls in this way completely removes action objects from agent functions, and makes the process of calling a specific action explicitly clear in the code.

\n
// Flat agent class.\npublic class Flat extends Agent<GlobalState> {\n\n    // Generic static action-creating function.\n    public static Action<Flat> action(SerializableConsumer<Flat> action) {\n        return Action.create(Flat.class, action);\n    }\n\n    // Vacancy message function.\n    public void sendVacancyMessage() {\n        if(!flat.isOccupied()) {\n            flat.getLinks(Links.VacancyLink).send(Messages.Vacancy.class, flat.size);\n        }\n    }\n}  \n\n// Use the static action method explicitly.\nrun(\n    Split.create(\n        Flat.action(Flat::sendVacancyMessage),\n        ...\n    );\n);
\n

This strategy makes for explicitly clear, easily maintainable code connecting agents and actions.

\n

Messages

\n

Messages should be defined in a shared message class so they can be used by the entire model. Individual messages should be defined as static classes inside the larger message class. Do not define messages inside agents, inside a model, or as many separate classes. This can lead to code duplication and difficulty in class maintenance.

\n

The Simudyne SDK provides built-in classes for messages which contain a single primitive type (integer, long, double, float, boolean) or an empty body. Modellers need only extend these built-in classes to get all the functionality they need.

\n
public class Messages {\n\n    // Custom message classes that extend the built-in message type for doubles\n    public static class Bid extends Message.Double {}\n    public static class Vacancy extends Message.Double {}\n}
\n

If a message needs to pass multiple different primitive types, but no complex objects or behaviour, extend the Simudyne SDK Message object.

\n
// Message class for price quotes, which passes only primitive types.\npublic class Messages {\n    public static class PriceQuoteMessage extends Message {\n        double price;\n        double reducedPrice;\n    }\n}\n\n// Class demonstrating usage of price quote messages.\npublic class Seller extends Agent<GlobalState> {\n    public static Action<Seller> sendPriceQuote() {\n        return Action.create(\n            Seller.class,\n            seller -> {\n                seller\n                    .getLinks(Links.BankLink.class)\n                    .send(\n                        Messages.PriceQuoteMessage.class,\n                        message -> {\n                            message.price = 3;\n                            message.reducedPrice = 2.3;\n                        };\n                    );\n            };\n        );\n    }\n}
\n

To send a complex data type, extend the Simudyne SDK Message.Object<T> generic object. Provide the name of the complex data type object in place of the \"T\" variable. When an agent receives a message containing a complex data type object, that agent has access to the complex data type's functions.

\n
// Message class for price quotes which passes a complex data object.\npublic class Messages {\n    public static class PriceQuoteMessage extends Message.Object<PriceQuote> {}\n}\n\n// Class demonstrating usage of complex price quote messages.\npublic class Seller extends Agent<GlobalState> {\n    public static Action<Seller> sendPriceQuote() {\n        return Action.create(\n            Seller.class,\n            seller -> {\n            seller\n                .getLinks(Links.BankLink.class)\n                .send(Messages.PriceQuoteMessage.class, new PriceQuoteMessage(...))\n            };\n        );\n    }\n}
\n

Agents And Inheritance

\n

When multiple agent types need to share some common functionality, modellers can reduce code duplication and build better defined agents using inheritance. Extend the Simudyne SDK Agent class with the base class, and then the derived classes can be implemented with their own unique functionalities. In the following example, an Accomodation agent is the base for two derived agent types, Hotel and Flat. All of these agent types can be used just like other agents which don't implement inheritance.

\n
// Accomodation base class.\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                // Send message if vacant.\n            };\n        );\n    }\n}\n\n// Flat derived class.\npublic class Flat extends Accomodation {\n    public Action<Flat> registerNewHousehold() {\n        return Action.create(\n            Flat.class,\n            flat -> {\n                // Register a new flat.\n            };\n        );\n    }\n}  \n\n// Hotel derived class.\npublic class Hotel extends Accomodation {\n    public Action<Hotel> registerBooking() {\n        return Action.create(\n            Hotel.class,\n            hotel -> {\n                // Make a new booking.\n            };\n        );\n    }\n}\n\n// Model containing actions for Accomodation, Hotel, and Flat.\npublic class myModel extends AgentBasedModel<GlobalState> {\n    @Override\n    public void step() {\n        run(\n            Accomodation.sendVacancyMessage(),\n            Household.requestHome(),\n            Split.create(\n                Flat.registerNewHousehold(),\n                Hotel.registerBooking()\n            );  \n        );\n    }\n}
\n

External Classes

\n

External classes should be used for functionality that is not specific to agents. This functionality may be needed by multiple agents or by the model, but should not be unique to a specific agent type. A data loader or distribution builder could both be reasonable uses for these external classes. Methods in these classes should be static so they can be accessed from anywhere in a model.

\n
// External distribution class.\npublic class Distribution {\n    public static EmpiricalDistribution loadDistribution() {\n        // Load a distribution.\n    }\n}\n\n// Flat agent class which uses the distribution class.\npublic class Flat extends Agent<GlobalState> {\n    public Action<Flat> registerNewHousehold() {\n        return Action.create(\n            Flat.class,\n            flat -> {\n                EmpiricalDistribution distribution = Distribution.loadDistribution();\n            };\n        );\n    }\n}
","headings":[{"value":"Actions and Sequences","depth":2},{"value":"Messages","depth":2},{"value":"Agents And Inheritance","depth":2},{"value":"External Classes","depth":2}],"frontmatter":{"title":"Class Organisation","toc":true,"experimental":null}},"site":{"siteMetadata":{"title":"Simudyne Docs","latestVersion":"2.6"}}},"pageContext":{"absolutePath":"/home/vsts/work/1/s/content/2.4/docs/practices/class-organisation.md","versioned":true,"version":"2.4","kind":"docs","pagePath":"/practices/class-organisation","chronology":{"prev":{"name":"Best Practices","path":"/practices"},"next":{"name":"Iterative Model Building","path":"/practices/iterative-model-building"}},"lastUpdated":"2026-04-21T13:56:54.847Z"}}