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.

Joey

On 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)
>
> Requirements
> ------------------
>
> 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.
>
> Approach
> -------------
> 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.
>
> Difficulties
> --------------
> 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.
>
> Thanks,
>
> Russell Thomas
> Computational Social Science
> George Mason University
>