[MUD-Dev] MUD Design Fundamentals (Was: Looking for
Jon A. Lambert
jlsysinc at ix.netcom.com
Sat Aug 30 15:07:27 New Zealand Standard Time 1997
On 29 Aug 97 at 14:25, Brian Price wrote:
> Hello all,
> I'm new to this list so I'll include a short intro in this followup.
> I'm a 35 yr old computer technician/circuit designer turned programmer
> who's had an interest in wargames and rpgs since the age of 16 or so. As
> I have had a non-formal education, I may at times present concepts in
> unfamiliar ways. (the following will no doubt be an example of this)
Hi Brian. I have similar interests in wargames and RPGs.
> A persistance system is used to take a 'snapshot' of a system or
> sub-system state at a particular point in time. The persistance
> mechanism can then restore the system or sub-system to that earlier
Yep. The granularity and nature of the persistence can vary widely.
> It consists of basically three layers; the system or
> sub-system to be 'persisted', a system to encode/decode the run-time
> state of the persistant system to a storage mechanism, and a storage
> mechanism to store that state info.
The model I'm attempting is not dissimilar, perhaps only in
1) Object manager subsystem - consists of several subsystems
a) transaction manager
b) cache manager
c) database manager
The database manager acts as a translator of a generic OO model into
a relational model. It translates inheritance, associations, user
data types into their relational counterparts. Late bound DML and
DDL are used frequently.
A few general guidelines I've used in my approach:
1) Each class maps to one or more tables. An object instance maps
to a row.
2) Aggregate classes map to one or more tables.
3) Many to many associations map to a distinct table.
4) One to many and one to one relationships are implemented using
5) A Superclass and each subclass map to a table.
Note: I am using single inheritance OO model much like Java's.
> A relational db can well be used as the store layer for a
> persistance model but you lose the structure and type ignorance.
Yes for external programs, unless they access your store through an
object broker, see above.
> Thus if you change the type of a class data member you must make a
> corresponding change in the relational db structure. Although this
> violates some OO design goals (ability to isolate/encapsulate
> changes), it has the advantage that the store layer can be
> manipulated outside of the program that implements persistance.
> Another advantage is that the store layer incorporates functionality
> that you will not need to implement in the app.
True but these changes can be encapsulated as well, if you attempt
a generic object to relational translation rather than a literal
Jon A. Lambert
More information about the MUD-Dev