Business Objects In Memory

[Jared MacDonald]

I am used to keeping business objects in a relational database. So
when I delete an object, it gets deleted from the database -- and
other objects that reference it typically have their references set to
null. E.g., an entry in the ORDER_DETAIL table has an ORDER_ID
pointing to a parent ORDER table. When the entry in the ORDER is
deleted, the ORDER_DETAIL record gets deleted. Alternately, I might
have a CUSTOMER table and a LOCATION table, where every entry in the
CUSTOMER table has a LOCATION_ID. When an entry in the LOCATION table
is deleted, the customer's LOCATION_ID is set to null.

All standard stuff - but then I worked on a project by myself that
didn't require a database; the contents of the application were simply
held in memory, as Java objects, and serialized out to a file when the
user quit or saved.

The problem was deletion. The user basically had an Outlook-type view
at the objects in the system, and could delete any of them at will. I
kept the "master set" of objects in a class called Database,
partitioned into the different types of objects for speed. But the
objects frequently had references to each other. For example:

class Location { ... }
class Customer
{
Location location;
}

And there were numerous relationships like this. My question is, was
there a good generic solution for, say, nulling out the Customer's
location when that location was deleted? The object was easily removed
from the Database, but I couldn't figure out any generic way for
taking care of all the possible references to that object from other
objects.

The best I could come up with was an observer model, where, for
example, the Customer instance would add itself as a DeletionListener
to the Database, such that whenever an object of type Location would
be deleted, the Database would notify all listeners, and the Customer
object would check if the Location that had been deleted was its
location.

Jared

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

The best I could come up with was an observer model, where, for
example, the Customer instance would add itself as a DeletionListener
to the Database, such that whenever an object of type Location would
be deleted, the Database would notify all listeners, and the Customer
object would check if the Location that had been deleted was its
location.

I think an easier way would be to categorize the objects into two
classes: Owners and Ownables. It's pretty similar to what you proposed,
but the Location and Customer objects take care of the relationship
themselves, without involving the Database.

interface Owner
// The owner keeps track of all ownables that it has registered
register(ownable)
// When the owner is deleted it will notify the ownables. It
will call the delete(owner) method of the ownables.
delete()

interface Ownable
// Sets the owner to null in this class.
delete(owner)

Implementations:

Class Customer : Ownable
Owner location

// The owner should be registered in constructor with
location.register(this)

delete(owner)
if owner == location then location = null

Class Location : Owner
// Add an ownable to some list
register(ownable)

// This method must be called before the object is deleted
delete()
for each ownable, call ownable.delete(this)