I don't have a lot of experience with the Factory pattern per se, but I have one bit of advice for you. Don't attempt to engineer an all-purpose system from the outset, for even the very wise cannot see all ends. The architectural needs of your system will become clearer as you implement more layers of functionality. Start small, test as you go, and don't be afraid to refactor cumbersome pieces of your design.JoeyOn Sun, Jun 28, 2015 at 9:23 PM, Russell Thomas <[log in to unmask]> wrote:Is anyone using the “Factory” design pattern to construct agents at run time? I am about halfway down this path and I’d love to learn from anyone else who has experience with this approach. (See “Difficulties” below)
The setting is modeling teams and organizations engaged in design (of artificial products), innovation (in how they do design), and qualitative learning (i.e. learning new skills, not just getting better at existing skills). In other words, I’m modeling endogenous innovation involving genuine novelty. My agents are (somewhat) cognitive and adaptive, particularly in their ability to acquire or develop novel capabilities during the course of a simulation run. Also I’d like to experiment with a wide variety of initial conditions regarding agent types and capabilities. In essence, what I’m looking for is agents that are dynamic bundles of capabilities (i.e. resources, action rules, etc.) rather than fixed capabilities as is the norm in most ABMs.
These requirements suggest the use of a “Factory” design pattern (see https://en.wikipedia.org/wiki/Factory_method_pattern for general description).
During start( ), the AgentFactory is an object that takes as input specifications for the agents (i.e. list of capabilities) and also other key objects (i.e. environment objects such as SimState). The AgentFactory class includes various pre-built templates and objects to produce an agent object of the specified type. (I have a large library of capability and processing objects.) Actions to be performed by agent at each time step is specified by a special-purpose language that describe sequences of tasks and their interdependencies. (Execution is by a simple O-O stack machine.) Each task execution records its results, and these results can be concatenated and logged in a file. Essentially, agents can “explain” what they did and why each step. This is useful for both debugging and also as experimental results.
Clearly, this approach does not result in fast execution and would not be suitable for a large population of agents and long simulation runs. My simulations will involve tens or at most a hundred agents, so it won’t be a problem for me.
Where I’m running into difficulty is in software design decisions: 1) how general-purpose to make the code, and 2) how to avoid unnecessary complications. The advantage of making it fully general-purpose is that it will (later) reduce the design and debug time for specific ABM designs. The disadvantage is that it takes more time now for thinking, planning, coding, and testing (e.g. debug capabilities for the special-purpose stack machine).
In pursuit of general functionality, I am probably making the software design too complicated. It would be nice to see what other people have done and maybe learn from their experience.
Also, I want to use built-in capabilities of Java and also available Java libraries. For example, when I get to the point where agent specifications will come from a text file, I’ll probably use ANTLR to parse my special-purpose task language. But I might be unknowingly “recreating the wheel” in many cases by creating my own classes for various low-level functions.
Computational Social Science
George Mason University