Bill Kohl's Object Oriented World

Bill Kohl

Subscribe to Bill Kohl: eMailAlertsEmail Alerts
Get Bill Kohl via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Beyond Patterns: Thinking Objects

A Social Metaphor for Writing Software

Algorithm: A detailed sequence of actions to perform to accomplish some task. - Webster "Interaction is more powerful than algorithms." - Wegner Metaphor: Using a known idea to impart understanding of a new unknown idea.

Patterns and use cases have become accepted tools for creating OO apps. For many designers they are their only approach. But getting the full benefit of OOP requires a new way of thinking about creating object-oriented applications. It is called "Thinking Objects." This article will offer a metaphor to help you understand and begin "Thinking Objects."

There are two ways of producing functionality in software that I would like to discuss: sequential (procedural, algorithmic) execution and interaction. People are familiar with sequential programming. It is the first programming paradigm taught and a natural way of thinking. It goes like this. For a given task (result), create a series of steps (and possibly sub tasks) and carry them out in sequential order. When the steps have been completed, the desired result is achieved.

Figure 1 shows the task of mowing the lawn. To perform this task we would carry out the sequential set of steps shown. After completing the last step we have mowed the lawn. Note that we have acted in a procedural way, carrying out a series of sequential steps. So, when accomplishing individual tasks, we think and act procedurally.

Interaction and the Division of Labor Metaphor
There is another paradigm for creating functionality; it is called interaction. Think about modern society. We live in an age of cars that think, man has gone to the moon, gene therapy, the Internet. It is a very complex society. And yet it runs smoothly while getting more complicated every day. If we were asked to simulate even a small part of this complexity with procedural programming, it would be a difficult task. How does our society do it?

We investigate this by looking at another example of achieving functionality: buying an automobile. If we wish to buy a car, we go to a dealership and meet a salesman who shows us cars. When we find what we want, we negotiate a price and the dealer has a contract printed for us to sign. Now we have to negotiate a loan, so we go to the bank and see a loan officer. Meanwhile, the auto salesman has applied for a title to our automobile. We return with loan in hand, giving the money to the salesman. He gives us the keys to the car and temporary title. We have achieved the functionality of buying a car. Notice that though we have carried out a sequence of steps, it has required the services of others to complete the process (see Figure 2). This is fundamentally different than mowing the lawn, which we did without any help. There we were able to act individually. Here, we act in cooperation with others whose functionality is carried out independently of ours.

Could we have bought the car without help? Would we have known how to create the sales contract, how to get temporary title, how to complete the paperwork and credit investigation to get a loan?

Probably not, but suppose we could have. What about the car, could we have designed it? Could we have built it? I think not.

Corporate Example
The example above lacks functional descriptiveness. So I want to offer another example of the second kind of functionality. In this example, the overall functionality produced is immediately identifiable; it is the goods and services provided by a corporation to its customers.

A corporation supplies a specific set of goods and services to its customers. These goods and services represent the corporation's functionality. Services represent obvious functionality while goods represent the functionality required to produce them. Let's look at how a corporation is structured to produce that functionality.

A corporation is an entity. It has facilities and employees. It has a mission and purpose. How does a corporation operate? It operates through it employees. Employees of a corporation have job assignments, and responsibilities that go with those job assignments. If all the employees carry out their responsibilities and these responsibilities have been assigned properly to achieve the corporation's objectives, it will be successful.

Here is the part of the corporation that supplies the functionality of fulfilling a customer's order (see Figure 3). In this diagram, we see four corporate employees. They will cooperate to fill a customer order. Our corporation makes a product so a product will have to be assembled to complete the order. The ellipse represents the corporate boundary.

What happens when an order comes in? The order clerk gets the order from a customer. He or she has some responsibilities to fulfill, for example creating a purchase order, filing it, distributing copies, etc. After completing these responsibilities, he or she takes the order and asks the parts clerk to fill the order. The parts clerk pulls the parts, reconciles the inventory and passes the parts and purchase order to the assembly clerk, asking him to assemble the order. The assembly clerk assembles the parts, which then become the product. The responsibilities of the assembly clerk may include logging the product and giving it an ID number. He then passes the purchase order and product to the shipping clerk. The shipping clerk must determine and affix the postage and place the order for pick-up by UPS.

Here four employees have worked together to complete the customer order. Each has done their job in filling the order and has cooperated (interacted) with other employees to complete the process. This example makes clear how employees with responsibilities interact to supply an overall functionality for the corporation. In so doing, employees need only know how to carry out that part of the process for which they are responsible. (The idea of responsibility in object-oriented programming was put forward by Wirfs-Brock, et al.

If you haven't guessed by now, I have been describing what we know as division of labor, or in software terms, interaction or collaboration. Division of labor is as old as human society. It was not invented. It simply evolved as the best means of handling social complexity. Modern societies could not exist without it.

So division of labor evolved to deal with complexity in society and does an excellent job of it. What other benefits might it have? It happens to be quite adaptable. At one time in the history of medicine, a person who became a doctor was just that, a doctor, not a heart specialist or intestinal specialist, just a doctor, one variety. You went to a doctor and he did it all. Today we have medical specialists. But instead of having to redesign society's division of labor structure to accommodate a new medical hierarchy, the structure simply grew through specialization to accommodate the new complexity.

Division of Labor
Well, since this second kind of functionality has turned out to have some cool benefits like complexity management and flexibility maybe we should say a little more about it. We would like to know what makes it work so well in managing complexity, where does its flexibility come from and what is required for its operation?

How does it manage complexity? There are two kinds of complexity we are asking about here: data complexity and functional complexity. The data component is easily identified. It is all of the factual or data knowledge of our society. Such things as statistical knowledge, anatomical knowledge and historical knowledge are data knowledge. The functional component can be thought of as all the processes that can be observed in a society, which we will call societal processes. Such things as mail delivery, automobile production, even sending men to the moon are examples of societal processes. From these, two types of process can be identified: discrete societal processes and complex societal processes.

More Stories By Bill Kohl

Bill Kohl works as a software architect for a large petroleum industry corporation. He has worked in software for more than 30 years, the last 15 of those in the OO world. His roles have included OO instructor and mentor, Smalltalk, C++ and Java developer, and for the last 6 years, software architect. He has extensive experience in developing object models for enterprise applications.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.