In a conversation that took place entirely in my head-yes, I am seeking professional help, thanks for asking-the tiny little object said to the great big object, "Don't you know that you don't conform to the CORBA IIOP specification?"

The great big object replied, "Why not?"

"Because you're a DCOM ActiveX control from Microsoft, that's why!" retorted the little guy. "You don't play by the rules."

"Rules? Whose rules?" wondered the great big object. "I make my own!"

Come again? If this conversation sounds silly and incomprehensible, you're not alone. Unfortunately, it's representative of the state of Internet objects today. Out in the so-called real world, the level of dialog among the companies involved in the future of the Internet is almost as jejune.

Would it surprise you to learn that this topic will be one of the most important in computing for the next decade or so? It's called distributed objects, and in some ways it's even bigger than the Internet, although very much a part of that phenomenon as well.

Because the industry thinks it's important, and because we will have to deal with both pleasant and unpleasant issues related to distributed objects in the near future, I thought it would be useful to attempt an introduction to the subject in this and the next column. This will be a little like explaining the Mona Lisa's smile using the vocabulary used for discussing n-dimensional Borel sets, but what the heck. It's a computer-magazine column. By now, most people who are in the know about computers recognize the terms "object" or "object oriented." Outside of the programming context, however-and sometimes even within it-these concepts remain murky. Let's start with a description of objects as we all know them.

A phone-y example

A phone-y example. A telephone, for example, is an object. You can pick it up, look at it, use it. How do you know it's a telephone? Without becoming submerged in technicalities, you know it by its shape-it has an earpiece, a mouthpiece, and some kind of base. While phones can vary from old-fashioned black rotary desk models to such fanciful designs as Mickey Mouse or a mallard duck, the basic properties remain the same: A phone has shape, color, size, weight, and so forth.

Phones also have a function: to aid in communication. To be more precise, they have several functions-dialing, answering, sending, and receiving. To use a phone, however, you don't need to know how it works. All you need to know is how to dial, either manually or through your computer.

Internally, a phone is fairly self-sufficient. Whatever information and functions it needs to operate are built in, with the exception, of course, of the actual numbers you want to dial. On the other hand, a single phone by itself is pointless. A phone needs an electrical current, telephone lines, and another telephone to connect to. In other words, it has to work with other objects in order to be useful.

Two phones-and a lot of other equipment in between- do quite a bit of communicating before your voice goes across the lines. Messages are sent back and forth to establish the protocol of connection and the rules of transmission. Each of the objects involved in the phone transmission-phones, lines, and switches-understands particular protocols. Once two phones have established a connection, they share properties like ringing, sending, and receiving.

Putting it together. Many of the terms I've just used to describe a telephone can be translated to the world of computers and object orientation. Moving from real-world objects like a phone to virtual-world objects like one representing a phone is not that big a step. The language is intuitive, because it resembles the language we use every day.

Representing a phone

In the real world, a "phone" has the properties mentioned above. In computer software, you can have a programmed object that represents a phone. This object has many of the same components (properties and methods) as a real phone. Perhaps you have seen communications programs that feature simulated phone interfaces with touch-tone buttons and even the simulated shape and color of a desk phone.

From a programmer's point of view, the cosmetic similarities between real-world and virtual objects are nice because they cut down on the training needed by users. But the real value of working with objects-and the reason object-oriented programming has become the norm-is that objects are self-sufficient units that can be designed, written, and debugged with much less complexity than other types of programs.

Objects also tend to be more reliable than traditional programs, so it's easy-and important-to design objects to be reused. In this way, developers are not having to constantly reinvent the wheel. They can simply plug in objects they've already created to a string of objects designed to perform a certain function. A phone object provides a good example of how this can work.

Object lesson. If you're writing a software program, you might have a half-dozen places where you need to provide the user with a way to dial a phone number. Rather than writing a new phone routine for each application, it's much easier to have one routine that can be used in all applications.