9/15/99 - Jack Harich - Go Back
Discussion
This moves into synthesis with Steve's ideas. One was using "slots" to define behaviors that must be supplied. Another was "all parts should look the same from the outside" whether they are leafs or containers. Both are reflected above. Part is the single interface defining the entire System Tree structure. The slots are named Objects in SlotMap.
The slots make Infinite Extensibility straightforward. Given a part "Type", clients can expect it to have one or more slots which together provide that part type's behavior. We expect Type to be a String name, with SlotMapInfo providing a list of information about each slot in SlotMap.
We need to consider if a "PropMap" is needed for extensible properties as well. This has the interesting distinction of customizable properties and behaviors. And what about all those boolean properties? Do they commit Part to limited reuse? They do clarify things, and provide a foundation....
To supply container behavior, a set of a dozen or two "core parts" are needed. The main ones are shown above.
Optional Interfaces are again used. The "Interface User" pattern which has been so useful shows up again. For example if a part instance implements the CellUser interface, then setCell(Cell) is automatically called when the part is initialized, allowing the part to use the Cell its in.
The big gain of this design is the single interface defining the entire System Tree structure. Everything else is a part. This essentially reduces what was the kernel down to a single class implementing Part. Running on that are the core parts. Running on them are the domain parts. This give a clean layered architecture.
A prototype is needed to verify that this is a productive way to go. It's so novel that more bottom up work is needed.
Evaluation
(do using Key Use Cases)