March 9, 2021
Hot Topics:

Thinking in Objects

  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Creating wrappers might seem like overkill, but there are many advantages to writing them. To illustrate, there are many middleware products on the market today. Consider the problem of mapping objects to a relational database. There are OO databases on the market today that are perfect for OO applications. However, there is one itty-bitty problem: Most companies have years of data in legacy relational database systems. How can a company embrace OO technologies and stay on the bleeding edge when its data is in a relational database?

First, you can convert all your legacy, relational data to a brand-new OO database. Anyone who has suffered the acute (and chronic) pain of any data conversion knows that this is to be avoided like the plague.

Second, you can use a middleware product to seamlessly map the objects in your application code to a relational model. This is a much better solution as long as relational databases are so prevalent. There might be an argument stating that OO databases are much more efficient for object persistence than relational databases.

Object Persistence

Object persistence refers to the concept of saving the state of an object so that it can be restored and used at a later time. An object that does not persist basically dies when it goes out of scope. For example, the state of an object can be saved in a database.

However, in the current business environment, relational-to-object mapping is a great solution. For brand-new OO applications that need to create new data stores, using an OO database might be a viable choice. However, OO databases have not gained wide acceptance.

Standalone Application

Even when creating a new OO application from scratch, it might not be easy to avoid legacy data. This is due to the fact that even a newly created OO application is most likely not a standalone application and might need to exchange information stored in relational databases (or any other data storage device, for that matter).

Let's return to the database example. Figure 2 shows the public interface to the class, and nothing else. Of course, when this class is complete, it will probably contain more methods, and it will certainly contain attributes. However, you as a programmer using this class do not need to know anything about these private methods and attributes. You certainly don't need to know what the code looks like within the public methods. You simply need to know how to interact with the interfaces.

What would the code for this public interface look like? Let's look at the open() method:

public void open(String Name){
   /* Some application-specific processing */
   /* call the Oracle API to open the database */
   /* Some more application-specific processing */

In this case, you, wearing your programmer's hat, realize that the open method requires String as a parameter. Name, which represents a database file, is passed in, but it's not important to explain how Name is mapped to a specific database for this example. That's all we need to know. Now comes the fun stuff—what really makes interfaces so great!

Just to annoy our users, let's change the database implementation. Last night we translated all the data from an Oracle database to an SQLAnywhere database (we endured the acute and chronic pain). It took us hours—but we did it.

Now the code looks like this:

public void open(String Name){
   /* Some application-specific processing */
   /* call the SQLAnywhere API to open the database */
   /* Some more application-specific processing */

To our great chagrin, this morning not one user complained. Even though the implementation changed, the interface did not! As far as the user is concerned, the calls are still the same. The code change for the implementation might have required quite a bit of work (and the module with the one-line code change would have to be rebuilt), but not one line of application code that uses this DataBaseReader class needed to change.

Code Recompilation

Dynamically loaded classes are loaded at runtime—not statically linked into an executable file. When using dynamically loaded classes, like Java does, no user classes would have to be recompiled. However, in statically linked languages such as C++, a link is required to bring in the new class.

By separating the user interface from the implementation, we can save a lot of headaches down the road. In Figure 3, the database implementations are transparent to the end users, who see only the interface.

Click here for a larger image.

Figure 3: The interface.


In this installment of the object-oriented thought process series, we began the process of starting to think in terms of objects. The though process is different when designing systems in an object-oriented manner. In the next column, we will continue this process by refining how we think in terms of objects and their messages.


Fowler, Martin. UML Distilled. Addison-Wesley Longman, 1997.

Gilbert, Stephen, and Bill McCarty. Object-Oriented Design in Java. The Waite Group, 1998.

Meyers, Scott. Effective C++. Addison-Wesley, 1992.

About the Author

Matt 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.

The articles in this series are adapted from The Object-Oriented Thought Process (published by Sams Publishing). 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.

Page 3 of 3

This article was originally published on April 30, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date