Objects Today

Object technology has changed the world of software development to a degree that can only be compared to the revolution that took place when operating systems were separated from the code residing in the computer: the degree of liberation for program development, the possibilities offered, the freedom to create new and powerful applications, are like nothing that existed before object-oriented technology came along. Without this approach, the user interfaces we have all grown to love and use extensively -- including the many, ever-growing faces of the internet -- would simply not be.

And what inherent characteristic of objects makes them so powerful for operating system and industrial application use? Actually, there are three elements of object technology that are, consistently and inseparably, responsible for the "magic" of objects: class inheritance, data encapsulation, and method messaging. In the following paragraphs, a nutshell explanation of what each is.

Data Encapsulation

Although all objects in an application are associated to the same data set, the context within which each object uses that data set is unique. An object has the capability to "ignore" what other objects in the application do, and responds only to the behavior for which it has been programmed. In fact, we can say that objects "remember" what makes their behavior what it is, and do not allow that memory to be altered. This means that an object's behavior is consistently predictable within an application. It also means that an object's behavior can be modified at any time without affecting any other objects in the application.

We can find a well-known parallel to this feature of objects in ourselves: the genes we each carry are all part of DNA molecules that have the same composition -- this makes us a species. However, the unique combination of these genes -- inherited from our parents -- makes us different from any other individual in the species -- including our parents: unique in appearance, intellect, and emotional makeup.

Class Inheritance

When creating an application, the uppermost levels of functional behavior are developed in the form of abstractions that contain a set of descriptions of the capabilities and characteristics that the objects in a given abstraction set, or class, will have. Any object that belongs to a given class "inherits" all the behaviors defined for that class, and possesses additional behavior that makes that object unique within that class.

Perhaps the best way to look at class inheritance is, again, through a parallel in nature, where the principle of acquired characteristics is everywhere. When we look at a living entity, say a frog, for example, all we see is the frog. A biologist, however, probably sees something like animal --> vertebrate --> amphibian --> frog --> Colombian Tree Frog. In this example, animal is the most abstract class to which the frog belongs -- the biologist would call it a kingdom -- and all the subclasses that follow inherit from it: all vertebrates are animals, all amphibians are vertebrates, all frogs are amphibians, and all Colombian Tree Frogs are frogs. By the same token, Colombian Tree Frogs have certain characteristics that no other frog species has -- a highly poisonous skin, for one. Likewise, frogs have anatomical and physiological features that no other amphibians possess, and amphibians are uniquely equipped to live both in water and in land, unlike any other vertebrates.

One thing to notice from the example is that the characteristics that distinguish each level in the Colombian Tree Frog's biological chain are additions to the characteristics inherited from previous levels. The significance here is this: if a Colombian Tree Frog stubs its toe, other Colombian Tree Frogs are left unaffected. Likewise, if a change in the environment causes a mutation in Colombian Tree Frogs, no other frog species will necessarily change. A change in one object does not affect any other objects in a class; a change in a class does not affect the classes from which it inherits.

Method Messaging

Unlike programming approaches that are function-driven -- that is, in which the same message goes to the same place in the same manner every time it is issued -- messages in the object world take place more as requests than as commands: the layering of classes and subclasses, on the one hand, and the encapsulation of data, on the other, serve as the basis for a messaging behavior that permits a request for action to be submitted by a given object in the program, without the need for that object to "know" which object will receive that message or how it will go about acting upon it. The most advantageous characteristic of messaging in the object world, however, is that , while two objects -- or two classes, for that matter -- can be altered in their behavior, the way in which the two objects or classes communicate will remain intact, and information exchange between them will not be affected. We can change the way objects work without changing the way they communicate.

Perhaps an apt illustration of the way in which objects communicate would be a comparison of object communication to the process of mailing a letter, as seen through the eyes of the sender: if I send a letter to a given address, it makes little difference to me -- the object sending the message -- whether I drop the letter in a mailbox , take it to the post office, or even ask someone else to mail it for me. Similarly, I'm neither concerned nor interested in knowing exactly what means of transportation will be used in carrying that letter to its final destination, or who physically handles the letter upon arrival, so long as it is read by the right person. When an object sends a message, it only matters that the message be received by the appropriate receiving object -- that it gets to the right destination; how is of no importance.

About Objects and Good Design

An ancillary benefit derived from developing applications in an object environment is that the reward for good system design is immediate, long lasting, tangible, and readily measurable: wise use of the principles of inheritance, along with the associated concepts of frameworks, allow for an increasing amount of "borrowed" programming to take place as a system is developed. This is known as reuse, and constitutes the single most important factor in the cycle time reductions and cost savings usually associated with development in an object-oriented environment. Well-designed object systems provide for more and more reuse as more and more applications are developed, in an ever-decreasing spiral of time-versus-process. The result, in terms of savings in modeling and protopyping, development time, and system testing, is nothing short of dramatic. Objects done right are, by far, the cheapest way to go!