Reply to thread

Message: [QUOTE="H. S. Lahman, post: 598488"] Responding to Mathers.... I don't think this is a design pattern issue; I think it is more of a tactical OOP optimization of a basic OOA/D. Per your first asterisk you have: [Monster] + type | * | | | * [Ability] which can be reified to: [Monster] + type | * | | | 1 [AbilitySet] | 1 | | | * [Ability] So each Monster has a reference to a table of its specific abilities. (If you need to navigate the other way, each Ability has a reference to a table of the Monsters with that Ability.) As an OOP optimization you can eliminate the collections by being clever about the identity of Abilities. Assuming the total number of Abilities is relatively limited, you can implement AbilitySet as a bitmap attribute of Monster where the bit position is the index into a fixed array of Ability references accessed by a static Ability::find(index). If the bit is set, the Monster has that Ability. Ability has a static table of its instances that is updated as the instances are created. The factory that creates Monsters can use external configuration data to obtain the bitmap value for a particular Monster type based on the Monster.type attribute. That can be read directly from a database. If the user can create custom monsters, then one can store the bitmap and the new type attribute for future reference. This pretty much limits memory to M Monsters + N Abilities + 1 static Ability table. The price will be performance in searching the bitmap and checking the Abilities to see if they are relevant. Note that at the cost of more bitmap attributes in Monster, one can also save the searching. The basic idea is to cross-reference Abilities with the Monster behaviors in exactly the same way: [Monster] + type | * | | | * [BehaviorSet] | 1 | | | * [Ability] where each BehaviorSet is a list of references to the Abilities that are relevant to a particular Monster behavior. In effect there is a BehaviorSet bitmap for each behavior that Monster has. These would be initialized in the same way as the first case. The next issue is providing a generic interface to Ability. From the examples cited, it seems that Abilities provide rather simple parametric data that affects or enables certain Monster behaviors. That is, Ability has no intrinsic behaviors. If so, I would suggest Ability be in a form similar to an A-V pair. (There are many variations, such as XML strings.) Then the relevant Monster behavior can test the the attribute name to determine how to apply the value in its context. (The direct search via AbilitySet would simply ignore attributes that were not relevant to the behavior in hand.) Then there is only one interface needed: getAttribute and getValue. (Note there is nothing to prevent an Ability from have multiple A-V pairs; the interface just has to be slightly more flexible.) [This sort of parametric polymorphism is a sort of analysis pattern, BTW. I have a number of examples that might be of interest on my blog in the section on invariants.] ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman [email]hsl@pathfindermda.com[/email] Pathfinder Solutions -- Put MDA to Work [URL]http://www.pathfindermda.com[/URL] blog (under constr): [URL]http://pathfinderpeople.blogs.com/hslahman[/URL] (888)-OOA-PATH [/QUOTE]

Verification