Using Object Persistence

 <  Day Day Up  >  

Object persistence is another issue that must be addressed in many OO systems. Persistence is the concept of maintaining the state of an object. When you run a program, if you don't save the object in some manner, the object simply dies, never to be recovered. These transient objects might work in some applications, but in most business systems, the state of the object must be saved for later use. In his book The Object Primer , Scott Ambler devotes an entire section to this topic.

Object Persistence

Although the topic of object persistence and the topics in the next section might not be considered true design guidelines, I believe that they must be addressed when designing classes. Thus, I introduced them here to stress that they must be addressed early on when designing classes.


In its simplest form, an object can persist by being serialized and written to a flat file. Although it is true that an object theoretically can persist in memory as long as it is not destroyed , we will concentrate on storing persistent objects on some sort of storage device. There are three primary storage devices to consider:

  • Flat filesystem ” You can store an object in a flat file by serializing the object. This has very limited use.

  • Relational database ” Some sort of middleware is necessary to convert an object to a relational model.

  • OO database ” This is the logical way to make objects persistent, but most companies have all their data in legacy systems and are just starting to explore object databases. Even brand-new OO applications must usually interface with legacy data.

Serializing and Marshaling Objects

We have already discussed the problem of using objects in environments that were originally designed for structured programming. The middleware example, where we wrote objects to a relational database, is one good example. We also touched on the problem of writing an object to a flat file or sending it over a network.

To send an object over a wire (for example, to a file, over a network), the system must deconstruct the object (flatten it out), send it over the wire, and then reconstruct it on the other end of the wire. This process is called serializing an object. (For an in-depth discussion on object serialization, refer to Java 1.1 Developers Guide by Jamie Jaworski.) The act of actually sending the object across a wire is called marshaling an object. A serialized object, in theory, can be written to a flat file and retrieved later, in the same state in which it was written.

The major issue here is that the serialization and deserialization must use the same specifications. It is sort of like an encryption algorithm. If one object encrypts a string, the object that wants to decrypt it must use the same encryption algorithm. Java provides an interface called Serializable that provides this translation.

 <  Day Day Up  >  


Object-Oriented Thought Process
Object-Oriented Thought Process, The (3rd Edition)
ISBN: 0672330164
EAN: 2147483647
Year: 2003
Pages: 164
Authors: Matt Weisfeld

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net