Communications of the ACM

Communications of the ACM

Building Objects out of Plato: Applying Philosophy, Symbolism, and Analogy to Software Design

By Ray Giguette
Communications of the ACM, October 2006, Vol. 49 No. 10, Pages 66-71
10.1145/1164394.1164396
Comments

Few of us think of Plato when designing software systems—but maybe we should. Viewing objects philosophically allows us to analyze them in new ways, borrowed not only from philosophy but also from art, music, psychology, and literature [4]. The analysis of literary symbolism in particular is surprisingly applicable to object-oriented design.

Unlike Cobol, Fortran, or even Pascal, object-oriented languages are based on the philosophy of Plato [5]. According to Plato, each real-world object is an approximation of its ideal form. A particular tree is an instance of the Tree form, which defines the characteristics all trees have in common. Plato might say that a Java class is similar to a platonic form, because it generalizes all possible class instances.

When we recognize that a particular tree is of the form Tree, or an instance of the Tree class, we are in a sense viewing that tree as a symbol. Like a symbol, the tree is a concrete representation of an abstraction (its form or class).

In literature, too, an object can represent an abstraction. A raven in a poem by Edgar Allan Poe, for example, might just be a raven...or it might symbolize Death, War, Witchcraft, or Wisdom. If we view a raven symbolically, its salient traits embody an abstract concept. As we read, we construct a mental mapping between raven traits and characteristics associated with this concept. This mapping forms an analogy, and the more raven traits included in the mapping, the stronger the analogy.

For instance, if a raven symbolizes Death, then its salient traits include its color, size, and ability to fly. Our reasoning might be as follows:

1. A raven is black, a color often associated with Death.
2. A raven is relatively large, which might represent the significance of Death.
3. A raven can fly, like the soul leaving the body.

In this interpretation, raven traits irrelevant to Death, such as the fact that it lays eggs, has feathers, and mimics human speech, are ignored (Figure 1).

---

"Leave my loneliness unbroken! Quit the bust above my door! Take thy beak from out my heart, and take thy form from off my door!" Quoth the raven, "Nevermore."

---

The mapping from a real-world object to an object class is also an analogy. For instance, a cupboard full of dishes is not literally a stack, but is analogous to one—if we equate adding and removing dishes with the push and pop methods of a Stack class. If the abstraction seems apt, then the choice of a Stack is a good one, even though characteristics such as the color of the cupboard may have no corresponding Stack attribute (Figure 2).

The system designer decides which object traits are relevant and how they fit the underlying abstraction. If we view the dishes too "literally," we might create a Stack that holds only dishes, implying that objects must have dish-like qualities in order to be stacked. By mapping all dish traits to Stack characteristics, we create a "forced" analogy, and a dependence between dishes and stacks that reduces the reusability of our Stack class.

Further analysis of the dishes may lead us to modify our analogy or choose a different underlying abstraction. If a dish can be inserted into the middle of the pile, then our Stack analogy is weak, and perhaps the dishes should be represented as a List. We can thus analyze the design of an object class as we would the meaning of a literary symbol, by examining the precision of our analogy.

Back to Top

The Literary Model of Abstraction

The use of symbolism allows a literary work to be viewed on different "levels," depending on how abstractly we view its meaning. Take as an example Poe's poem The Raven. The narrator of the poem, trying to forget the death of his beloved Lenore, is taunted by a raven that flies into the room, perches on a bust, and periodically caws "Nevermore!" We can view The Raven on at least three different levels:

1. On one level, the poem can be taken literally. The raven is simply a raven, and the poem reveals only Poe's eccentric character.
2. On another level, the poem explores the narrator's complex mental state, symbolized by the raven's traits and actions.
3. On a third level, the poem makes a universal statement about Grief, and the raven symbolizes the inescapable nature of Death and Sorrow.

Note that each level requires a more abstract interpretation of the raven: from a bird, to one man's emotional state, to Sorrow itself. Viewing the poem at a high level of abstraction also allows us to categorize it in terms of a literary theme, such as Love and Death or Man vs. Himself.

We often view software at different levels of abstraction during the design process, as we gain a better understanding of the problem. Our analysis of the dishes might reveal levels of abstraction similar to those of The Raven:

1. On one level, the dishes are literally dishes, unique items rather than members of a class.
2. On another level, the dishes collectively form an object symbolizing an entire class, with class characteristics such as LIFO access.
3. On a third level, the concepts of Dish and LIFO are separated, creating the independent, "universal" concept of a Stack that can be reused in other programs.

At the highest level, we may identify the software's theme or class, such as Traveling Salesman or Knapsack.

Back to Top

Literary Analysis in Software Development

Thus objects and symbols are in many ways comparable abstractions, as summarized by the table here. To take advantage of these similarities, literary analysis methods can be incorporated into object- oriented software development. Here is an example:

A team of software developers is designing a new game. One component of the project is the Scenario Builder, software that can create variations of the game in order to extend its lifetime. The supervisor of the design team, having just read Hemingway's The Old Man and the Sea, decides to base the game on this story. He describes the plot to his development team:

"Every day for three months an old Cuban fisherman named Santiago goes out in his boat to fish, but he catches nothing. Then one day he travels far out to sea and catches the largest fish he has ever seen, a 1,500-pound marlin so long he must tie it to the side of his boat. As he returns home, sharks attack the carcass of the fish, tearing off pieces of its flesh. Santiago fights off the sharks with a club, but by the time he gets back to shore the marlin has been completely devoured."

The supervisor reads aloud a word problem that he feels captures the essence of the story:

"A fisherman has a marlin weighing 1,500 pounds. Assuming his boat is 90 miles from shore and traveling 5 mph, and that the fish is being devoured by 11 sharks at a rate of 2.7 pounds per minute per shark, how much of the marlin will be left when the boat reaches shore?"

In the game version, the user can play either Santiago or the sharks. If he plays Santiago, his goal is to catch a marlin and get it to shore—and the level of victory is based on the number of sharks killed and the amount of marlin remaining. If he plays the sharks, the player must find Santiago's boat and eat as much marlin as possible.

The supervisor outlines the key object classes:

1. Santiago class. Santiago can row, fish, and hit sharks.
2. Marlin class. A marlin has speed and weight, and can be caught and eaten.
3. Shark class. A shark has speed, can smell and eat marlin, and has 100 hit points.
4. Boat class. A boat has size and speed.
5. Sea class. The sea affects the movement of fish and boats.

The team members feel this interpretation is somewhat limited. They say the story isn't just about Santiago catching a fish; it symbolizes his entire life, his struggle against the sea. The supervisor agrees.

Thinking of ways to improve the Scenario Builder, the supervisor notes similarities between The Old Man and the Sea and Jaws. He suggests that the game allow various numbers of men and sharks, and that the Shark class be expanded to include different types of carnivorous sea creatures. Furthermore, adding vessels such as whaling schooners and submarines to the Boat class will permit scenarios similar to Moby Dick and 20,000 Leagues Under the Sea.

Comparing Hemingway's story to other literary works gives the supervisor an idea. The story isn't about one man, it represents Man's struggle against Nature. Why not define scenarios in which Santiago and various animals hunt each other, not just in the sea but in multiple environments?

---

"I have never seen or heard of such a fish. But I must kill him. I am glad we don't have to kill the stars."—Santiago

---

The developers set to work altering the supervisor's classes and designing new ones:

1. Person class (the old Santiago class). People can hunt, fish, trap, and so on.
2. Prey class (super class of the Marlin class). This class includes "food" animals such as marlin and deer that Santiago might hunt.
3. Predator class (super class of the Shark class). This class includes animals such as sharks, tigers, and snakes that might hunt Santiago.
4. Vehicle class (super class of the Boat class). This class includes boats, camels, trucks, and planes.
5. Environment class (super class of the Sea class). This class includes subclasses such as the sea, forest, desert, and jungle, and determines which prey, predators, and vehicles are allowed.

The developers have difficulty defining the Prey, Predator, and Person classes, because they appear to intersect. Santiago himself might hunt for, or be stalked by, a predator such as a tiger. They also feel that Santiago's success depends largely on his motivation and character, and that the "Santiago" class should include attributes such as courage, strength, and endurance. They wonder if Marlins and Sharks should have some of these traits as well.

As the concept of Prey and Predator merge, the team searches for other interpretations of the story. One programmer with personal issues suggests that the sharks might represent humans who feed off of the work of others, or people who prey on the weak and attack the individualist. This prompts the supervisor to define the game as the struggle between Santiago and various opponents (including natural forces and other men) to achieve a particular goal.

This results in more class additions and changes:

1. Goal class (super class of the Prey class). Goals include killing animals, killing men, getting treasure, arriving at a destination, escaping capture, and staying alive.
2. Hero class (super class of the Person class). The Hero must achieve one or more Goals. Some team members assert that the Hero need not be human. He might even be a shark.
3. Antagonist class (super class of the Predator class). The Antagonist is anything that thwarts the Hero, and includes classes such as Person, Predator, Weather, and Illness.
4. Setting class (the old Environment class). This class determines not only the environment, but also which Goals, Heroes, and Antagonists are appropriate for a given scenario.

At this point, the developers reflect upon how their view of the game has changed. At first they viewed Santiago and the sharks literally, and developed a single scenario. In order to reuse Santiago and the sharks in other scenarios, they viewed them symbolically, as instances of Person and Predator classes. Finally, to maximize reusability (and to better understand the story), they viewed Santiago and the sharks as symbols of increasingly abstract concepts. This resulted in viewing each scenario as an instance of a Game abstraction, and identifying common Game characteristics (Figure 3).

Using only a cursory analysis of Hemingway's story, the design team has greatly increased the generality of the Scenario Builder. The supervisor realizes that a game based on The Old Man and the Sea is something of a special case, but he wonders if other software systems can be designed in a similar fashion.

Back to Top

Conclusion

A modern program is a narrative, in which the specification is the theme, the algorithm is the plot, and the objects are the characters. If we analyze a program as we do a story, we might ask what is the author really saying? Perhaps a program that finds a path through a maze is more than that. Maybe the problem has characteristics common to other searches. Maybe the doors between rooms symbolize Connectivity, and the path to the exit represents the steps needed to solve a problem. Which view of the program, literal or figurative, helps us create general, reusable object classes?

Though computer scientists often favor a mathematical view of abstraction [1–3], often what is needed is the eye of the artist or philosopher. Math and computer science students are not trained to compare subtly different abstractions to find the best one, yet literature, philosophy, art, and psychology students learn this very skill by analyzing the meaning of symbols.

To design a program or a class we must understand it. Constructing a symbolic analogy helps us do that, just as Poe used symbols to explore the nature of Sorrow, and Plato used forms to explain our perception of reality. Before coding even a simple Stack, we must know the meaning of LIFO itself.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2006 ACM, Inc.