A reference to an object can be either hard or soft, and it can be either an ownership or pointer.
A reference to an object can also be categorized as either ownership or pointer:
These reference types define four relationships between objects: hard ownership, soft ownership, hard pointer, and soft pointer.
A hard ownership reference defines the relationship between objects when one object owns another object; the owned object cannot exist without the owner and the owner requires the owned object until the owner exists. The following examples are hard ownership references:
A soft ownership reference defines the relationship between objects when one object owns another object; the owned object cannot exist without the owner, but the owner does not need the owned object. The following examples are soft ownership references:
A hard pointer reference defines the relationship between objects when one object requires another object for viability; these object can have different owners. The following examples are hard pointer references:
A soft pointer reference defines the relationship between objects when one object refers to another object, but these objects can exist independently. The following examples are soft pointer references:
A hard reference protects an object from a purge. For example, an entity contains a hard pointer to a layer. Therefore, a layer cannot be purged until it is pointed to by one or more entities. When a new database is written out from an existing database (for example, in the WBLOCK operation), all hard pointers are copied into the new database. A soft reference is simply a pointer to an object that does not protect the referenced object from a purge. When an object uses a soft pointer to another object, it should check whether the object still exists before opening it.
For example, the database must contain predefined symbol tables of layers, linetypes, blocks, text styles, etc., and the database can contain dictionaries of colors, multiline styles, materials, groups, etc. The layer table must contain the predefined layer record, named the zero layer, and can contain any user-defined layer records. The linetype table must contain three predefined linetype records, named the continuous, byLayer, byBlock, and can contain any user-defined linetype records. The block table must contain the model space block record and can contain any user-defined block records. A block record can contain any entities or can be empty. An entity requires a layer to which it belongs and a linetype by which it is drawn. An entity can contain XData that can refer to a color stored in the color dictionary. The following diagram demonstrates the reference types between these objects:
There are five classes for working with these four types of relationships between objects:
These five classes are derived from the OdDbObjectId class and inherit its functionality. They only redefine the comparison operators for own applying. These classes provide the specialization of the object ID for various types of relationships between objects within a database.
Identifying the Objects of Databases
Copyright © 2002 – 2020. Open Design Alliance. All rights reserved.
|