Karianna: /* Structural rules */

2009-08-14T12:52:31Z

‎Structural rules

Karianna: Created page with '=Summary= # Store items granted to the PC (such as a Feat) # Store items available to the PC (such as a starting language list) # Quickly answer "does the character have X" quer...'

2009-08-14T12:52:18Z

Created page with '=Summary= # Store items granted to the PC (such as a Feat) # Store items available to the PC (such as a starting language list) # Quickly answer "does the character have X" quer...'

New page

=Summary=

# Store items granted to the PC (such as a Feat)
# Store items available to the PC (such as a starting language list)
# Quickly answer "does the character have X" queries
# Not confuse availability with granting
# Track the source of every grant and availability
# Be able to cleanly handle MULT:NO v. MULT:YES
# Track exact sources (there are some nasty cases I will draw out later)
# Handle removal of one MULT:NO parent while another is present to maintain the state (such as a user selection of a CHOOSE)
# Appropriately store a CHOOSE result so it can be reused by other tokens/objects (so it has to be stored in a predictable location)
# Replicate behavior from the existing tokens in PCGen 5.16.
# 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.
# Handle undo/redo.

=Structural rules=

# 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)
# 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)
# 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)
# It should be fully unit testable, without major dependencies on other objects. (some will be expected)
# It should have as simple of an interface as reasonably possible (if you're beyond 20 methods, you probably have a problem)
# It will not expose its internal state to external modification other than through direct method calls.
# You must not consume any errors (no catch Throwable or anything like that)
# It should not produce side effects - methods do one thing. No surprises for the uninitiated.
# It should be a class that does one thing.
# You must assume CDOMObjects are not cloneable.
# It should minimize special cases.
# It should have no knowledge of the UI
# It should minimize the number of mental models another programmer needs to learn (see 11)
# It should be built with as few classes as reasonably possible (but not at the expense of clarity or requirement (9) above.)
# 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.
# Known patterns / data structures should be used when appropriate (see 13)

=Recommendation=

Type Safety is good

Back to [[Architecture]]

@@ Line 30: / Line 30: @@
 # It should minimize the number of mental models another programmer needs to learn (see 11)
 # It should be built with as few classes as reasonably possible (but not at the expense of clarity or requirement (9) above.)
-# 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
+# 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.
 # Known patterns / data structures should be used when appropriate (see 13)

Character Data Store - Revision history

Karianna: /* Structural rules */

Karianna: Created page with '=Summary= # Store items granted to the PC (such as a Feat) # Store items available to the PC (such as a starting language list) # Quickly answer "does the character have X" quer...'