Character Data Store

Summary

1. Store items granted to the PC (such as a Feat)
2. Store items available to the PC (such as a starting language list)
3. Quickly answer "does the character have X" queries
4. Not confuse availability with granting
5. Track the source of every grant and availability
6. Be able to cleanly handle MULT:NO v. MULT:YES
7. Track exact sources (there are some nasty cases I will draw out later)
8. Handle removal of one MULT:NO parent while another is present to maintain the state (such as a user selection of a CHOOSE)
9. Appropriately store a CHOOSE result so it can be reused by other tokens/objects (so it has to be stored in a predictable location)
10. Replicate behavior from the existing tokens in PCGen 5.16.
11. It should also avoid making the assumption that it's a d20 system. Assume it needs to handle Rolemaster & Serenity if you're looking for particular challenges.
12. Handle undo/redo.

Structural rules

1. It must be a directed acyclic graph, with no cycles in the code. (And the use of an interface solely to break a cycle is sometimes, but not always indicative of a structural problem)
2. When a developer makes a code modification, the developer should not be forced to make a matching modification in another location in the code in order to maintain a valid structure (no contracts, as I would call them)
3. When a change is made to the internal data structure, a significant amount of "reorganization" to ensure a valid data structure should not be necessary (if you're incrementing through everything, then that's not good)
4. It should be fully unit testable, without major dependencies on other objects. (some will be expected)
5. It should have as simple of an interface as reasonably possible (if you're beyond 20 methods, you probably have a problem)
6. It will not expose its internal state to external modification other than through direct method calls.
7. You must not consume any errors (no catch Throwable or anything like that)
8. It should not produce side effects - methods do one thing. No surprises for the uninitiated.
9. It should be a class that does one thing.
10. You must assume CDOMObjects are not cloneable.
11. It should minimize special cases.
12. It should have no knowledge of the UI
13. It should minimize the number of mental models another programmer needs to learn (see 11)
14. It should be built with as few classes as reasonably possible (but not at the expense of clarity or requirement (9) above.)
15. Pools (e.g. skill points) must be stored in something that can be recalculated from a known good source. Simply a numerical map that developers are trusted to update correctly is not appropriate. We have demonstrated the challenges of that model in 5.x.
16. Known patterns / data structures should be used when appropriate (see 13)

Recommendation

Type Safety is good

Back to Architecture