What is an Object?

by Niranjan Ramakrishnan

Of all the words in the lexicon of software technology, 'object' may be the most ambiguous, with the possible exception of that perennial joker card, 'system'.

The problem arises from a historical anamoly. Those who invented Simula (1967 - just imagine that!) called it an object-oriented language. It was a language based on classes. if they had simply called it class-oriented programming, there would have been no confusion. But they chose to call it object-oriented programming. It thus started with a paradox - a technology that depended on classes, but used a different (and somewhat opposite) term instead. From then on, terminology in this area has been in an Abu Ghraib of its own.

The relationship of classes to objects is a long and complicated one. It has been the dream of every programmer to have data that can be agglomerated, disciplined, predictable, able to hold both knowledge and action, yet be individually expandable. With classes, the first set of conditions were met. Individual expandability was restricted to variant behavior based on state or transient information (function parameters, say). There was no way an instance could overrule the template imposed by its class. The subtext of this was that every instance would belong to a class. Individual expandability (or contractability) is the distinct hallmark of an object.

In this sense a language like JavaScript is more object-oriented than a language like Java. In the former, you can add properties (including functions) to individual instances, without forcing them to belong to a class. This is true object-orientation -- a world built out of objects that are governed by their own properties and act according to their own lights, as opposed to class-orientation, where all instances are regimented according to pre-defined rules. Over time, there have been efforts to introduce languages to permit prototype-oriented programming even if not fully object-oriented programming, but most have these have remained in their own small arenas, while the larger world is dominated by strongly typed languages.

The first thing that pops into anyone's mind when called upon to differentiate an object-oriented language from a procedural one would be to use the word 'class'. Yet, when asked if object and class mean the same thing, the expert shifts from one foot to another, and launches into a discourse on meta classes and Russell's Paradox.

A better solution is to talk about classes and instances. Here the meanings are unambiguous. A class is a recipe, the instance is a product. No confusion. What is an object? Still a problem. An object is, from an academic view, technically the same as an instance. It is sloppy to refer to a class as an object, but the habit is so widespread it is practically impossible to enforce any verbal discipline. So, the best thing to do when you hear someone speaking of an object X is to ask, "Did you mean a class called X, or did you mean an instance called X?"

Archives: See PSJ Archives

What's good about UML

by Niranjan Ramakrishnan

To paraphrase Stephen Colbert from his recent speech, where he said something about that government being best which governs least, one reason I like UML is because of the large number of things on which it is silent. Instead of coming up with impossible figures for every conceivable need, it has contented itself with a few diagrams, and left the door wide open for text. Notes is one example. Constraints is another. Both can be written up. As is the idea of elaborating use cases, of which more below.

UML is very good about making visual the structural connections between classes. The Object Model Diagram is elegant, a pleasure fully discernible only to those who have lived through the era of Boochian clouds. The idea of breaking down all connections between classes/objects into subtyping, association, aggregation or composition is clean and simple. Rearranging these relationships is also relatively easy.

The State diagrams are similarly natural. This is a natural outgrowth of Harel's Statecharts of old and the state transition diagrams of systems theory. I love the way states can be fitted within superstates, and putting the resulting arrangment into an object model. This forms the State design pattern, whose benefit is to offer a surrogate class hieararchy for state-dependent behavior, without having to subject a class to the harrowing experience of choosing to align along one axis of behavior or another. Yes, you can have it all (in this case).

The places where UML is weakest, in my view, are all related to the historical weakness of all such attempts, the efforts to capture algorithmic logic in pictures. From the oldest days of the flowchart (an old professor of mine used to remark that it was easier to write the program than it was to draw the flowchart!), this has seemed more trouble than it was worth, Still, it is invaluable to have a documentation of which classes interact in the process of executing a use case, and in what sequence. The Collaboration Diagram actually combines the Object Model Diagram with the elements of algorithm to give a sense of both the structural and procedural interconnections. This is a contribution from HP's old Fusion Methodology. However, it is rarely used any more, and in my 9 years of teaching UML, I have come across almost no organization that prefers Collaboration Diagrams to Sequence Diagrams.

Activity Diagrams are an afterthought, and were not part of the original release of the UML, if memory serves. They were introduced when it was discovered that the UML was a popular tool for modeling workflow. Their chief contribution is to provide a way to explore parallelism in workflow execution. A further afterthought was to introduce the so-called 'swimlanes' to accommodate objects. They are used as a brainstorming tool at the beginning of the project, and as a documentation tool at the end.

We have left out the first of all the UML diagrams -- the Use Case Diagrams. My own experience is that the diagrams are more historical than useful. After all, how much benefit is drawn from pointing out that such and such an actor calls upon such and such a use case? Still, for whatever it is worth, it may provide a bird's eye-view of the entire project. This is hardly to say that the use case exercise is without value. Far from it. The benefit of the use case exercise lies in the elaborations, namely, the writing down of the pre and post conditions and exceptions that lie in the path of a use case. This exercise provides an low-budget preview of what lies ahead in the logical progression of the application.


Reference Courses:

Object-Oriented Analysis and Design - Using the UML
Object-Oriented Design Patterns

Archives: See PSJ Archives