Developers Manual 1.20
|
|
|
1. Defining the Object Model
1.5 Dependent Objects
When defining your object model, you may notice subtle differences in the relationships between objects. As an example, consider the following extract from the specification of class Person:
define: #homeAddress as: Address;
define: #gender as: GenderAt first glance, the relationships described here are the same - each instance of Person will hold a single instance of Address in its homeAddress instance variable, and a single instance of Gender in gender. However, if one considers the relationship on another level there is a difference - an instance of Gender will likely be shared by different Person objects, whereas the Address object held in homeAddress will only belong to one individual Person.
The significance of this is as follows: when the contents of a Person's homeAddress instance variable is overwritten (by another instance of Address, or nil) the replaced Address object is no longer referenced from any other persistent object, and so should be removed from the database (deleted). Further, when an instance of Person is itself removed from the database, then its homeAddress object should also be deleted for the same reason. On the other hand, since the object held in gender is shared by other objects it should not be deleted in either of these cases.
In ReStore, relationships such as that between a Person and its homeAddress are termed dependent relationships - the object held in homeAddress is dependent on the owning instance of Person for its existence. By explicitly declaring this dependency, then ReStore knows to delete the instance of Address when overwritten, or when the related Person instance is deleted. Declaring a dependent relationship is done simply by sending the message dependent to the class of dependent object in the class specification method:
define: #address as: Address dependent;
define: #gender as: Gender
Dependent Collections
Collection-based relationships may also be dependent. In the Entertainment Shop example application, the class CompactDisc maintains a collection of CDTrack objects in its tracks instance variable. This is a dependent relationship - if an individual CDTrack is removed from the tracks collection, or the owning CompactDisc is deleted from the database, then there will be no further references to that CDTrack and it should be removed from the database. This relationship can also be declared dependent by sending the message dependent to the class of dependent object:define: #tracks as: (OrderedCollection of: CDTrack dependent)
Of course, the management of objects necessitated by dependent relationships could also be accomplished by explicit coding within your model classes. However, by carefully considering the nature of object relationships during the class specification stage, you can avoid such complications and further reduce the overhead of adding persistency to your applications.
1.5 Dependent Relationships