Objects:  Let's Get the Definition Right (And See Where That Takes Us)

In this article I will attempt to clarify the orthogonality (independence) of Object Oriented thinking to Procedural thinking. This will lead to a refined definition for Objects and then a discussion of what this means for developing Object Oriented applications.

Two Programming Paradigms

There are many ways (computer language paradigms) to program a computer to satisfy a given set of requirements. Object Oriented and Procedural are two such paradigms. The Procedural paradigm views a program as data and functions that operate on that data. Requirements of an application are satisfied by sequential execution of the statements composing the program. The significant elements of a procedural program are a main function which controls the overall flow of execution and functions which are called for specific tasks required during execution. Assignments to variables, repetitive looping and conditional execution are the other major elements of procedural programs.

In the Object Oriented paradigm, programs are composed of objects that interact with one another to fulfill the requirements of the application. This interaction takes place through messaging. Objects are said to “send” messages to other objects requesting services (functionality) of the other object. Other elements important to Object Oriented programming are encapsulation, inheritance, polymorphism and identity. I will assume the reader is familiar with these properties.

Today, the accepted definition of an object is:

Object a software entity having properties and behavior. (Some authors add that objects represent real world entities.)

It is this definition of an object that I believe needs some refinement.

This definition has evolved fromSimula, the first Object Oriented language. Simula was designed for simulation modeling of real world problems. Objects in Simula represent the real world entities of the simulation. In their software implementation, they have the properties and behavior of those real world entities which are relevant to the simulation. This is the origin of the Object definition above. All succeeding Object Oriented languages have, de facto, accepted this definition of an object.

Object Oriented Applications

One of the steps in the development of an Object Oriented application is to identify the objects which will compose the application. Software designers and programmers often struggle with identifying these objects. Various techniques have been put forward to help, and these are usually successful in finding a set of objects for building an application. These techniques assume the definition given above to be a complete description of an object. I believe this definition is overly restrictive. It does describe many of the potential objects of most applications; but it also restricts the discovery of a class of objects that do not fit this definition and whose identification would be beneficial to the quality* of these applications.

The World of Objects

To begin my proposal of refining the definition of an object, I would first like to restate the accepted definition, adding the property of encapsulation. I don't believe anyone will disagree with this definition.

Object an encapsulated software entity having properties and behavior

I'm leaving off the part about representing real world objects because today our object oriented applications are no longer simulations and instantiate many objects which are not of the real world; for example Lists, Strings, etc. (We will be examining further refinements to the above definition further onwards.)

What is encapsulation? In the Object Oriented world, encapsulation means that the internal structure of an object, its properties and behavior, can only be accessed through the object's interface; the interface being that set of messages the object exposes to other objects through its encapsulation layer. Why did I want to add encapsulation to the definition of an object? To explain, letâ€^TMs look at the structure of a Simula object.

In the initial formulation stages of Simula, Nygaard indicated that an object's internal structure could be implemented with “local data and procedures defined outside the high level language [Simula]”.1 I believe that he was indicating that Simula would provide the framework for simulation. The objects themselves, their internal structure, could be programmed in some other language. Simula 67, the current version of the language, is considered a superset of AOLGOL 60, a procedural language. So the “local data and procedures” (an object's internal structure) of a Simula 67 object have the syntax of a procedural programming language and may contain all the constructs normally found in procedural code, assignments, looping, conditionals, etc. So abstractly, from an internal perspective, the Simula object can be viewed as a procedural entity. Each object is also defined by an interface, the set of requests (messages) it will respond to. The object's internal structure is protected (encapsulated) by denying direct access to the internal structure of the object. An object's functionality is made accessible by those method signatures exposed in its interface.

If we now consider one of the modern Object Oriented programming languages, say Java, we find that the description of an object in Simula given above, fits perfectly with how one would describe a Java object. Java objects are encapsulated and expose their functionality through method signatures contained in their interface. Internally, a Java object's data and methods are implemented in a procedural syntax similar to that of the C language, a procedural programming language. The most significant difference between a Simula and a Java application is the “object only” characteristic of the Java application.

What is it about encapsulation that makes it so significant? Encapsulation divides an Object Oriented application into two distinct regions: the internal structure of the objects, and the region external to all objects where interaction takes place. To better grasp the significance of this, I ask the reader to use their imagination as follows. Imagine we could observe, from an internal perspective, a running Java application (picture the cliché image of going “into the Matrix”) in which the properties and methods of the objects are private, (i.e.- encapsulation is fully enforced). We are within the application, but outside of the objects of the application. We are in the space where interaction via messaging is taking place. From this perspective we would not be able to see objects executing the code of their methods. That functionality is hidden by encapsulation. We would only see objects sending messages and receiving responses to those messages. We can see the interfaces of each object which are exposed through their encapsulation layer. It is significant to note that in this space of an OO application, exterior to the objects of the application, there exist no programming constructs from the procedural world. There is not the slightest hint of a do loop, or an assignment or a conditional or any procedural computer construct. Nothing procedural, only objects and messages. (I like to think of this world as the “object world” of the application.) What is the significance of this observation?

[Aside: At this point there may be some who point out that messaging occurs sequentially in a Java application. Looking at an OO application this way is missing the point of the paradigm entirely. Alan Kay once remarked that in OO programming we have the view that “computation is simulation” [Kay 1977]. True simulation can only proceed if each object of the simulation, software or scaled model, reacts independently to its environment. Some sequencing may or may not occur in the simulation; but sequencing is not a property of simulation. I believe that obtaining this view of the “independence” of the objects of an OO application is important to making the paradigm shift from procedural thinking to OO thinking.]

First, it emphasizes the orthogonality between the object oriented and the procedural paradigms. The object world is entirely non-procedural. It is where the object oriented paradigm exists. A place where procedural thinking is out of place. When designing an object oriented application, the thinking process is completely different than designing a procedural application. It is commonly called “Thinking Objects” and means we design by creating the functionality of the application through interaction of the objects of the application. And secondly, it means that while objects internally are creating their functionality procedurally, the application is creating functionality through the messaging/interaction ( i.e.- the OO paradigm). Abstractly, these are two completely different paradigms occurring within the application. The observer mentioned above, who is watching the objects and their messaging, if asked to describe an object of the application, would only be able to give as a definition, a list of the messages in that object's interface. In other words, they would describe each object of the application by its interface. From the observer's point of view, an object cannot be defined by the de-facto definition in today's Object Oriented literature, as having properties; because to this outside observer, an objectâ€^TMs properties cannot be seen.

A More Accurate Object Definition

The result of this observation allows the definition of an object to be stated without referring to properties. I believe the correct and most general definition of an object is

Object - an encapsulated software entity containing functionality and an interface to that functionality

This definition makes no mention of properties and implies that in the Object Oriented Paradigm, there can be objects without properties. (Note that an object without properties will most likely have state; but that state will be transitory. There will be no properties in its definition.) As a more general statement, the object-oriented paradigm allows us to model not only entity objects, but any abstract concept for which behavior can be identified. (See my article “Beyond Entity Objects” here (http://java.sys-con.com/node/46233).)

Let me give just one example of such an object. Suppose you are building a package delivery application for Fed X. During the design phase you identify a Network type object. It could represent networks at any level of the Fed X distribution system. These networks may change from time to time and perhaps even new (sub) networks are being added to the system. These networks will need to be built and modified by the application. So you identify a NetworkBuilder type object. This object has all the functionality needed to build or modify a network, but no properties. Pass this object all the data required to build or modify a network and it will return the new or modified network. It may have temporary state while doing so, but that state is gone once the new or modified network is passed back to the requester.

Where does this take us?

Now let's see where this new definition of an object takes us in the task of creating an Object Oriented application. First, during your application development process, the field of view for prospective objects of your application will be significantly increased. Not only will you have the entity objects of the problem domain and the software objects of the computer language you are using, lists, strings, etc.; You will also be open to the possibility of objects such as the NetworkBuilder described above.2 Secondly, you may also be open to new metaphors which can be used to develop the object model for the application. One such metaphor I will describe below. I do not mean to say that traditional methods for discovering objects should not be used. Indeed, identifying entities of the problem domain by looking for nouns within the requirements, finding objects through use-cases, etc. are valid starting points.

A Metaphor for Thinking Objects

Let me test your imagination in another direction. Imagine that you have been given a task to do, a very complex task, you have just been told to put a man on the moon by the end of this decade. (Kennedy, â€^TM62) Your response, “Hey, wait a minute, no one has done that before. Why me? I donâ€^TMt know anything about Space, or Rockets, or Apogees or anything like that.” But Kennedy gives you 10 billion dollars and you do have a friend at MIT who is a Rocket Scientist. So you call him and he is your first hire. The two of you get together and start planning what kinds of specialists you will need and how to organize them and within weeks NASA is born. 7 yrs later we land on the moon and youâ€^TMre saying to yourself, “Isnâ€^TMt Division of Labor wonderful.” You knew nothing about how to get to the moon, but you had some friends who did and you were a good organizer. So hiring the right specialists and creating an efficient organization to manage the specialists, to see that they collaborated effectively to build a space ship, test it thoroughly and make it to the moon, you completed a task of immense complexity. (It didn't quite happen this way; but what the heck, literary license.)

The metaphor of Division of Labor (go here (http://java.sys-con.com/node/48535) to see a more through discussion of the Division of Labor metaphor) will help you to begin thinking in terms of objects interacting. Imagine your applications as complex tasks you have been given (requirements) and to complete them you are going to need a set of specialists (objects) and efficient organization (patterns or some organizing scheme of your own making) to solve the problem. Of course the first question is how do I pick these object specialists? Iâ€^TMll get to that. But the first step is to know that youâ€^TMre looking for them.

The complexity of putting a man on the moon is staggering, much more than any one person could accomplish. But the task was broken up into smaller chunks whose complexity one person (or a team of specialists) could handle. Each one of these decomposed tasks concerned only a specialized field of knowledge. These tasks were cohesive in their requirements. The idea of a specialist is critical here for two reasons. First because it manages complexity (smaller tasks are less complex) and secondly because it focuses on a particular specialized area of knowledge (or area of the requirements). Ok, now for the question: “How do I find the specialist objects to create?” That answer is and isnâ€^TMt easy. A few examples may be helpful.

A Unit of Work

A utility company wishes to serve its customers better by making sure every customer request is serviced on time. In their current system, which relies on manual routing of requests from inception to completion, customersâ€^TM requests sometimes get lost or shuffled to the bottom of the stack resulting in slow turn around time for that customer. They would like a new automated system that electronically routes customer orders and tracks their progress reporting when an order exceeds certain pre-programmed time limits. Customer orders include new service, termination of old service, and repair of existing service. You are to design and write this application.

In the business world there are 2 major kinds of applications you will run into: Data maintenance applications and Business Process (work flow) applications. This application is of the Business Process kind. Now ask yourself the question “What specialists would I need to accomplish this job and what coordination hierarchy would I need?” To begin with, if I wish to make sure no order is misplaced, lost or slowed down, I would want to assign every order to an employee whose only task is to push this order through the process and never lose track of it. You might identify this the class of this object with a name like OrderManager, or perhaps more preferably UnitOfWork. The UnitOfWork object then will be responsible for moving a customer order through the process required for that order. This corresponds to the horizontal level of coordination in a business process. Since there are 3 types of orders customers might place, there will be a hierarchy for UnitOfWork classes, an abstract UnitOfWork class and 3 subclasses, NewService, TerminationOfService and Repair. Requirements for each of these classes would include electronically routing of the order, maintaining response time-outs so that the proper authority can be notified if the order is slow in being processed and closing out the order when the process is complete.

Each UnitOfWork will have to deal with various departments and be responsible for various documents that accompany the order. Those departments might include Accounts, Billing, Maintenance, and Installation. Initially, I would assume a Façade object for each one of these departments. There would also be objects representing business logic required for interfacing with each department. So we may have an AccountsSupervisor, BillingSupervisor, etc. These objects would be responsible for creating forms associated with their department, creating database entries where required, etc. This suggests that there would be an object for each different form. As a rule, developers have far too few classes in their applications. So donâ€^TMt worry about adding new classes as you think of them. In addition, the UnitOfWork object may want to delegate some of its responsibilities for timing to a Timer object. The timer, once started, would run until timeout at which time it notifies the associated UnitOfWork of its timeout. We will need an email server object that can be obtained from open source. Notice that I have not been concerned with implementation details. For example, Timers will require a TimerManager that can re-instantiate them from the DB when necessary. For simple DB maintenance applications in addition to classes representing DB tables there may be a Validation hierarchy and manager objects for those objects that are formed from multiple DB tables.

A Distribution Network

A package delivery corp wishes to create an automated distribution and tracking application. Every package would be tracked from start to finish so that customers could go online and follow the course of their shipment and so that alerts could be sent if a package delivery exceeded pre-programmed limits. Right away we see the possibility of using the ‘UnitOfWorkâ€^TM concept to track a package. It could be named many things, but Iâ€^TMll call it a PackageMonitor. There is a significant difference here from the earlier example. The packages are delivered through a network of hubs until reaching their final destination. If routing to one hub is unavailable (due to space limitations or equipment malfunctions) the package is routed through a different set of hubs to the final destination. This means that the package monitor will not know in advance what route the shipment will take. This suggests that we may need a RouteManager that determines the routing of the package. Since the RouteManager will be responsible for routing all shipments from a hub, there will be only one route manager object for each hub. Some shipments entail a delivery receipt to be returned to the sender.

A Natural Gas Pipeline Application

A natural gas pipeline transports gas from production fields to end users. The production fields are owned by parties other than the pipeline and the end users (typically municipal gas distribution companies or electrical generating plants) are also independent parties. Shippers, who may or may not be producers or users, contract with the pipeline to move gas from a Point A to another Point B. At Point B, the gas may be sold to another Shipper who has contracted with the pipeline to move gas from Point B to Point C, or to an end user, in which case the gas leaves the pipeline. Shippers wishing to transport their gas under the terms of their Contract, create daily Nominations specifying the quantity of gas and the start and end points for transport. Besides physical points on the line such as Point A above, there is a concept called Pool Point Pool Points have no physical representation on the pipeline and are used by shippers to buy and sell gas among themselves without incurring transport charges. The pipeline also contracts with Operators. Operators own metering stations controlling the flow of gas onto and off of the pipeline. On any particular gas day, after shippers have entered their nominations, the Operators check the nominations for their metering stations and Confirm the quantity of gas they can actually flow on that particular day. Some Shippers may not be able to ship as much as they desire.

From this simple description of a natural gas pipeline operation, we can extract a number of entity objects that would be found in the final application: Shipper, Operator, Nomination, Confirmation, PipelinePoint, PoolPoint and Contract. These are all persistent objects and would generally be referred to as domain objects. The final application also contained a number of conceptual objects found in the problem and/or solution domain. Here is a list of classes for those objects and a short description of their usage.

Validation (with subclasses NominationValidation and ConfirmationValidation) â€" the validation classes encapsulate the business rules concerning shippersâ€^TM nominations and operatorsâ€^TM confirmations.

Path â€" the route taken, real or imaginary, by gas from the start point to the end point of a nomination.

GasTransfer â€" an object responsible for proper distribution of a shipper's gas to his contractual delivery entities. (This object existed purely in the solution domain but was a critical object to the success of the application.)

PipelineSupervisor â€" coordinates the pipeline activities of nominating, confirming and scheduling.

NominationSupervisor, ConfirmationSupervisor, SchedulingSupervisor â€" carry out the relevant activity for the PipelingSupervisor.

PipelineNetwork â€" a directed graph modeling daily transactions on the pipeline. (This object also existed purely in the solution domain and was a critical object for obtaining an efficient solution.)

NetworkBuilder â€" responsible for building the PipelineNetwork.

None of these conceptual classes is persistent, yet all of them represent functionality found in the problem domain. Without these conceptual classes, the function they represent would have been distributed among the entity objects of the application. This would lead to a lack of cohesion and significantly increased coupling among those objects, creating a more brittle, less maintainable or extensible application.

In this article I have attempted to clarify to the reader the complete orthogonality between Object Oriented thinking and procedural/functional thinking. Object Oriented thinking is used to design an Object Oriented application. Procedural thinking is used to implement the objects discovered in the design process.

* quality - reusability, maintenance, extensibility

1. "The Development of the SIMULA Languages" by Kristen Nygaard, Norwegian Computing Center and University of Oslo and Ole-Johan Dahl, University of Oslo

2. Michelle Yaiser gives a description of objects that I like. “Think of an object as a model of the concepts, processes, or things in the real world that are meaningful to your application.” https://www.adobe.com/devnet/actionscript/learning/oop-concepts/objects-...