Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
This series, The Object-Oriented Thought Process, is intended for someone just learning an object-oriented language and wants to understand the basic concepts before jumping into the code or someone who wants to understand the infrastructure behind an OOP language they are already using. Click here to start at the beginning of the series.
In keeping with the code examples used in the previous articles, Java will be the language used to implement the concepts in code. One of the reasons that I like to use Java is because you can download the Java compiler for personal use at the Sun Microsystems Web site http://java.sun.com/. You can download the J2SE 1.4.2 SDK (software development kit) to compile and execute these applications and I will provide the code listings for all examples in this article. I have the SDK 1.4.0 loaded on my machine. I will also provide figures and the output (when appropriate) for these examples. See the previous articles in this series for detailed descriptions for compiling and running all the code examples.
In the previous article in this series, I covered the topic of object signatures. Despite the fact that object signatures may seem like a fairly basic concept, they are in fact the cornerstones of object-oriented design. The design of the object signatures defines how the objects are used. These signatures can define brand new object services or they can interface to currently existing services. This is where the term of object wrappers comes into play.
In the next few columns, you will explore the concept of object wrappers by considering several interesting technologies. In many ways, object wrapping is simply another example of the paramount object-oriented concept pertaining to separating the interface from the implementation.
Perhaps the most obvious topic to illustrate this concept is that of data handling—saving program data to external media with the intent of restoring it later. The basic idea is to develop a way to encapsulate various data access technologies and make them transparent to the user. In short, you will create a single interface that will allow the user to save and restore an object, regardless of the technology.
In this article, you will investigate the process of serializing an object so that you can write it out to a file. Next month, you will create wrappers that will allow you to write data from a Java program using JDBC to a database (your first example will be Microsoft Access). In the process of these next few articles, you will focus on the concept of object wrappers. After you cover the topics of object serialization and connecting to a database, you will see the power of object wrappers first hand.
Interface/Implementation Revisited
The overriding concept behind object wrappers is that of the separation of the interface from the implementation. By now, you should have realized that this concept is the basis of much of the material in this column. Thus, when designing a class, what the user needs to know and what the user does not need to know are of vital importance. Encapsulation is the means by which nonessential data is hidden from the user.
Consider the example of designing and producing a simple toaster. The toaster, or any appliance for that matter, is simply plugged into an interface, which is an electrical outlet. All appliances can access electricity by complying with and using the correct interface: the electrical outlet. The toaster doesn’t need to know about the implementation, or how the electricity is produced. A coal plant or a nuclear plant could produce the electricity—the appliance does not care which, as long as the interface works.
As another example, consider an automobile. The interface between you and the car includes components such as steering wheels, gas pedals, brakes, and ignition switch. For most people, aesthetic issues aside, the main concern when driving a car is that the car starts, accelerates, stops, steers, and so on. The implementation, basically the stuff that you don’t see, is of little concern to the average driver. In fact, most people would not even be able to identify certain components, such as the catalytic converters and gaskets. However, any driver would recognize and know how to use the steering wheel because this is a common interface. By installing a standard steering wheel in the car, manufacturers are assured that the people in their target market will be able to use the mechanism.
If, however, a manufacturer decided to install a joystick in place of the steering wheel, most drivers would balk at this, and the automobile might not be a big seller (except for some eclectic people who love bucking the trends). On the other hand, as long as the performance and aesthetics didn’t change, the average driver would not notice whether the manufacturer changed the engine—part of the implementation—of the automobile.
It must be stressed that the interchangeable engines must be identical in every way—as far as the driver’s perceptions go. Replacing a four-cylinder engine with an eight-cylinder engine would change the rules just as changing the current from AC to DC would affect the rules in the power plant example.
The engine is part of the implementation, and the steering wheel is part of the interface. A change in the implementation should have no impact on the driver, whereas a change to the interface might.
Interfaces also relate directly to classes. End users do not normally see any classes—they see the GUI or command line. However, programmers would see the class interfaces. Class reuse means that someone has already written a class. Thus, a programmer who uses a class must know how to use the class. This programmer will combine many classes to create a system. The programmer is the one who needs to understand the interfaces of a class. Therefore, when I talk about users in this article, I mean designers and developers—not end users. And when I talk about interfaces, I are talking about class interfaces, not GUIs.
To encapsulate data, classes are designed in two parts—the interface and the implementation.
The Interface
The interface is the services that are presented to an end user. In the best case, only the services that the end user needs are presented. Of course, which services the user needs may be a matter of opinion. If you put 10 people in a room and ask each of them to do an independent design, you might receive 10 totally different designs. There is nothing wrong with this. However, as a rule of thumb, the interface to a class should contain only what the user needs to know. In the toaster example, the user only needs to know that the toaster must be plugged into the interface—which in this case is the electrical outlet.
Perhaps the most important issue when designing a class is identifying the audience, or users, of the class.
The Implementation
The implementation details of the interface services are hidden from the user and can be changed as long as the interface remains the same. Recall that in the toaster example, although the interface is always the electric outlet, the implementation could change from a coal power plant to a nuclear power plant without affecting the toaster. There is one very important caveat to be made here: The coal or nuclear plant must also conform to the interface specification. If the coal plant produces AC power, but the nuclear plant produces DC power, there is a problem. The bottom line is that both the user and the implementation must conform to the interface specification.
Using Wrappers to Hide the Implementation
How does the concept of interface/implementation relate to the discussion on serialization and connecting to a database? The basic idea is that you as a user of a class should be able to write an object to a persistence data storage device without knowing what the implementation of the device is. This holds for specific implementations like whether or not you use an MS Access database or an Oracle database, and so on. It also holds true for the actual means of storage, like whether or not you use serialization or connect to a database. In short, all you should have to do is write the object; the underlying implementation should be hidden. In this way, you can change the implementation without affecting the user code. You will explore this concept in great detail after you cover the specific technologies. As stated earlier, this article describes object serialization; the next will cover connecting to a database using JDBC. Then, you will build the appropriate wrappers to allow you to seamlessly use one or both of these technologies. Thus, you can see how to write an object to a file.
Serializing an Object
No matter what type of business application that you create, saving the data to a storage device most likely will be part of the mix. In fact, one of my favorite lines when it comes to software development is “it’s all about the data.” In short, no matter what hardware, operating system, applications software, and so forth, is used when creating a software application, the data may well be the reason for creating the system in the first place.
Persistent Objects Basics
Recall that when an object is instantiated by an application, it lives only as long as the application itself. Thus, if you instantiate an Employee object that contains attributes such as name, ss#, and the like, that Employee object will cease to exist when the application terminates. Figure 1 illustrates the traditional object life cycle.
Figure 1: The Object Life Cycle.
When the Employee object is instantiated and initialized, it has a specific state. Remember that the state of an object is defined by the value of is attributes. If you want to maintain the state of the Employee object, you must take some sort of action to save the state of this object beyond the life of the application. The concept of saving the state of an object so that it can be used later is called persistence. Thus, you use the term persistent object to define an object that can be restored and used independent of the application. Figure 2 illustrates the traditional object life cycle with persistence.
Figure 2: Object Life Cycle with Persistence.
There are many ways to save the state of an object. Some of these are as follows:
- Save to a flat file
- Save to a relational database
- Save to an object database
Saving to a Flat File
The first example I will cover is that of using a flat file for object persistence. I define a flat file as a simple file managed by the operating system. This is a very simple concept, so don’t get too caught up in this description.
Note: Many people do not like to use the term flat file. The word flat implies that the object is literally flattened, and in a way it is.
One of the things that you may have thought about is the fact that an object cannot be saved to a file like a simple variable—and this is true. In fact, the problem of saving the state of an object has led to a complete software application industry, which I will explain at length later in this article. Normally, when you save a number of variables to a file, you know the order and type of each variable, and then you simply write them out to the file. It could be a comma-delimited file or any other protocol that you may determine.
The problem with an object is that it is not simply a collection of primitive variables. An object can be thought of as an indivisible unit that is composed of a number of parts. Thus, the object must be decomposed into a unit that can be written to a flat file. After the object is decomposed and written to a flat file, there is one major issue left to consider—recomposing the object, basically putting it back together.
Another major problem with storing objects relates to the fact that an object can contain other objects. Consider that a Car object may contain objects like Engines and Wheels. When you save the object to a flat file (or anything else for that matter), you need to save the entire object hierarchy, Car, Engines, and the like.
Java has a built-in mechanism for object persistence. Like other C-based languages, Java largely utilizes the concept of a stream to deal with I/O. To save an object to a file, Java writes it to the file via a Stream. To write to a Stream, objects must implement either the Serializable or Externalizable interface.
Serializing and Marshalling Objects
You have already seen the problem of using objects in environments that were originally designed for structured programming. The middleware example, where you wrote objects to a relational database, is one good example. You also touched on the problem of writing an object to a flat file or sending it over a network.
Basically, to send an object over a wire (for example, to a file, over a network), the system must deconstruct the object (that is, 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. The act of actually sending the object across a wire is called marshalling 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 de-serialization 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.
Serializing a File
As an example, consider the following code for a class called Person:
import java.util.*;
import java.io.*;
class Person implements Serializable{
private String name;
public Person(){
}
public Person(String n){
System.out.println("Inside Person's Constructor");
name = n;
}
String getName() {
return name;
}
}
This is a simple class that contains only a single attribute representing the name of the person.
The item of note here is the line that identifies the class as Serializable. If you actually inspect the Java documentation, you will realize that the Serializable interface really does not contain much; in fact, it is meant solely to identify that the object will be serialized. Below is a short description from the J2SE API specification.
| public interface Serializable |
|---|
|
Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.
About the AuthorMatt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, and C# .NET as well as various web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process, which is now in it’s second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb’s Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada. Related Stories Developer.com features tutorials, news, and how-tos focused on topics relevant to software engineers, web developers, programmers, and product managers of development teams. In addition to covering the most popular programming languages today, we publish reviews and round-ups of developer tools that help devs reduce the time and money spent developing, maintaining, and debugging their applications. This includes coverage of software management systems and project management (PM) software - all aimed at helping to shorten the software development lifecycle (SDL). AdvertisersAdvertise with TechnologyAdvice on Developer.com and our other developer-focused platforms. MenuOur BrandsProperty of TechnologyAdvice. |
