An Object-ive View of Data

My introduction to the idea of a logical data structure came back in 1982, during my first year out of college (Rice U in Houston) and my first year as an IBM employee (first of my 17 years with Big Blue). I was training to become an IBM Systems Engineer (field technical support person), and as a part of that training I learned something about the hierarchical form of data organization implemented through IBM's IMS database management system. While that structure made some sense to me (I'd seen organization charts and family tree diagrams that were hierarchical in nature), it took me a while to understand how data elements that were on the same level of an IMS database hierarchy but under different parents were linked to each other. I wasn't so good with pointers (though I knew people who were pointer wizards and could fix these things if they broke).

A couple of years later, I attended a branch office meeting in which we learned of a newly announced database management product called DB2. To me, the relational model, with data elements arranged in tables with rows and columns, made all kinds of sense, as did the intuitive and set-oriented Structured Query Language (I was an applied math major in college, and relational database technology is a prime example of applied mathematics). Over the next 16 years, I learned a lot more about DB2 and happily worked with people who were leveraging the technology for their employers' benefit, serene in my belief that the theory of data structuring had advanced as far as it needed to. Relational was a great thing. Who would want to deal with data in any other logical form?

Then, early in 2000, I left IBM to work for CheckFree, a leading user of DB2 and other relational DBMSs in the financial services industry (CheckFree is now a part of Fiserv Corporation). That's where I first worked extensively with application architects, and that's where I got my first exposure to object-oriented programming. Let me tell you, I had a tough time getting my arms around the notion of data being logically presented in the form of an object. I went to a couple of my Strategic Technology Team colleagues, Rick McMichael (still at CheckFree, now a VP there) and Mark Harris (now a senior consultant at Magenic), and asked, "Would you explain object-oriented programming to me?" Rick and Mark are a couple of very sharp guys, and they were patient with me, but still I struggled mightily to understand even basic OO concepts. "Well, an object is an instance of a class," one of them would say. My response: "What's a class?" "Look, you might have a set of plans for a house, and then you have the house itself. An object is to a class kind of as the house is to the building plans. Got it?" Me: "Uh..." When Rick delved a little into user interface programming and started talking about how, in the OO world, it was pretty easy to programmatically tell a box to draw itself, my eyes probably started to glaze over, and that particular discussion didn't last much longer.

Over the course of the next several years, I gradually absorbed more object knowledge, first from Rick and Mark and later from other CheckFree colleagues such as Don Barton, Matt Humphrey (now a Senior Program Manager at Microsoft), and Eric Drudge (now with Moneta). Eventually, I came to be somewhat comfortable talking about objects. I'll try now to put the concept of objects, as they pertain to data, in my own words. If you're an OO expert, cut me a little slack (but feel free to offer critique via a comment).

At the most basic level, I think of an object as an informational instantiation of something. Going back to the analogy mentioned previously, a house is a material instantiation of a set of building plans. Computer programs deal with data, not with two-by-fours and nails and copper tubing, and that's why I call an object an informational instantiation of something. Of what? Of a class. My former CheckFree colleague Matt described a class "as a convenient way to package data and behavior (code)." Added Eric Drudge, "a class is sort of the definition of an object." A class has attributes that indicate the defining characteristics of an associated object, and methods that indicate what the object can do.

Eric provided me with an analogy that really helped me to get my arms around the object concept. Suppose there is a class called Dog. Attributes of this class might include name, breed, color, gender, and age. The class could contain methods such as Bark(), Sit(), Sleep(), Eat(), and Fetch(). These methods would form the interface by which other programs would interact with an instance of the class. One such instance of the class (a dog object) might be "Fifi," a "poodle" that is "white," "female," and "2" years old.

Now, OO programmers don't think of data in an object sense just to confuse us database people. The object representation of data actually has some very useful characteristics when it comes to developing applications. One of the most important of these object aspects is called inheritance, and it has to do with a new class (again, an object is an instance of a class) being an extension of an existing one, and having all the attributes of the class on which it's based while also having some specialized attributes that are not shared with the base class. Consider, for example, the relationship between employees and managers (the latter being employees, but with attributes that are not shared with non-management employees). This relationship is pretty straightforward from an object point of view. On the relational database side, this relationship can be represented in more than one way, involving perhaps an EMPLOYEE table and a MANAGER table, but that schema view of the data is going to differ from the object-oriented view. Presenting data from a relational database to programmers in object form generally requires some code (either user-written or purchased, in the form of an object-to-relational mapping tool), and that means an investment of time and/or money.

Is making that investment important? If you're interested in programmer productivity, I believe that it is. The veteran OO programmers that I know don't want an object representation of data because they can't deal with schemas. They certainly know what a schema is, and they can deal with that and many of them have a good knowledge of SQL. These people want to deal with an object representation of data because it enables them to do what they do best - write code that delivers valuable business functionality - in a more time-efficient manner than would be the case if they had to work with a schema representation of data. In addition, your organization can benefit from another important aspect of object-oriented programming, called encapsulation. The idea here is that a class should be designed with a well-defined interface, so that it can be operated on only via specific methods. In other words, programs dealing with the data part of a class should act on the objects defined by the class, as opposed to acting on the data directly. The advantage of encapsulation - and this is a recurring theme of service-oriented architecture, or SOA - is application change isolation. Application maintenance will be less onerous if aspects of a class that could change in the future are hidden from programs that might use the class.

Am I an object expert? Nope. Not by a long shot. I have found, however, that learning what I can about object-oriented development and the related view of data helps me to walk a ways in an OO programmer's shoes. That puts me in a better position to be of help, as a data-focused person, to OO developers. These are people that you want to help, because they turn the data you manage into information, and that is a key driver of organizational success.