Another prominent software development paradigm is the object oriented paradigm. While the procedural paradigm is task-based, that is, it focuses on the actions the software should accomplish, the object oriented paradigm is task-based and data-based. Hence the object oriented paradigm groups together relevant data and tasks in entities known as objects. Consider the example of a list of numbers. According to Brookshear [1997], "in the traditional [procedural] paradigm, this list is considered merely a collection of data. Any program accessing this list must contain the algorithms for performing the required manipulations. Thus the list is passive in the sense that it is maintained by a controlling program rather than having the responsibility of maintaining itself." In the lesson on the procedural paradigm, a good example of such a list was given. The list was maintained by a set of modules and subprograms that operated on the list. For example, the subprogram Find smallest number took the list as input and returned the location of the smallest number in the list.

In contrast, the object oriented paradigm treats the list and the associated operations as one entity known as an object. Brookshear [1997] continues: "In the object oriented approach, however, the list is considered an object consisting of the list together with a collection of routines for manipulating the list. They may include routines for entering a new entry in the list, detecting if the list is empty, and sorting the list. In turn, a program accessing this list does not need to contain algorithms for performing these tasks. Instead, it makes use of the routines provided in the object. In a sense, rather than sorting the list as in the [procedural] paradigm, the program asks the list to sort itself." Thus the object oriented paradigm is task-based because it considers operations such as entering a new list entry or detecting an empty list. However, it is also data-based because these operations are grouped with the relevant data which in this case is the list of numbers.

The diagram to the right represents a generic object in the object oriented paradigm. The private data corresponds to the list in the example above, and the methods correspond to the list operations such as entering a new entry in the list, detecting if the list is empty, and sorting the list. Not every object, however, will use a list to organize its data. Some objects may contain only basic data types such as characters, integers, or reals, while other objects may incorporate complex data types such as trees or graphs. The methods of the object will always consist of operations that access or manipulate the object's private data. Programs which want to use an object can access the object's methods through a specific interface. The interface specifies how to send a message to the object, that is, a request for a certain operation to be performed. The interface for the list object previously discussed would require that any message for adding a new number to the list include the number to be added. The interface might also require that any message for sorting specify whether the sort should be ascending or descending. The table below summarizes some of the basic definitions which are important in the object oriented paradigm.

Object a collection of private data and a set of operations that can be performed on that data [Balci 1996].
Method an operation for accessing and manipulating data within an object.
Message a request for a specific action to be performed by a specific object.
Interface a collection of methods which specify how messages can be sent to an object.

To illustrate the idea of an object another way, consider modeling a grocery bag as an object. This object will need private data to store the contents of the bag (in this case, the bag will store various fruits) and the object will need methods for manipulating the data. The applet below represents such an object. Notice that the interface is given on the right side of the applet. This interface lists all the appropriate actions that can be performed on the bag object. Each of the actions listed represents a single method of the object. Notice that some of the methods require additional information that must be specified in the item box. For example, the method Put item will always add the item displayed in the item box to the contents of the bag. Similarly, Get item will remove the specified item from the bag. Try sending some messages to the bag object by following these directions:

  1. Add one of each type of fruit to the contents of the bag. To do this, first select the fruit from the drop down list. Then send the Put item message by pressing the appropriate button.
  2. Send the message to ask whether the bag is full.
  3. Send the message to ask whether the bag contains an apple.
  4. Send the message to remove an apple from the bag.
  5. Send the message to remove a pear from the bag.
  6. Ask whether or not the bag is empty.
  7. Remove any item from the bag (Hint: use the method Grab an item).
  8. Ask the bag how many items it contains.
  9. Empty the contents of the bag.

The bag object illustrates another important concept in the object oriented paradigm called encapsulation. Encapsulation means that a user sees only the services that are available from an object, but not how those services are implemented [Balci 1998]. In this case, the services available are represented by the methods in the interface. While anyone can manipulate the object according to the services available, only the designer of the object knows the details of how these services are implemented. Examining the bag object again, it is not possible to tell how the methods such as Put item or Get item are implemented. All the user can see is that the appropriate items are added and removed when the message arrives.

Encapsulation users see only the services available from an object, but not how those services are implemented [Balci 1998].

The idea of encapsulation implies that an object can be viewed from two different perspectives. Sometimes these perspectives are called the abstract view and the implementation view. The abstract view is what the user sees when he or she uses the object. From this perspective the interface of the object is visible but not the details of how the object executes its methods or stores its private data. The implementation view, however, is what the designer of the object sees. From this perspective, all the details are revealed. The queue object below demonstrates these two views. Click the "View Queue Object" button to show the queue. The interface for the queue has only two methods: Enqueue item and Dequeue item. The third button, "Show Implementation," is used to hide or reveal the implementation of the queue and is not part of the interface. To enqueue an item, first type a letter in the item box, then send the Enqueue item message by pressing the appropriate button. After enqueuing a couple of items, click "Show Implementation" to see how the queue object stores its private data and executes its methods. Try adding and removing a few letters from the queue with the implementation view visible. For more information on how queues work, see Queues: The Abstract View in the Data Structures module.

Displaying the implementation of the queue object reveals the design details of the queue. An array of characters stores the private data, and the methods are implemented using head and tail pointers to keep track of the ends of the queue. While these details are important to the designer of the queue, the user does not need them. In fact, it would be far better for other software modules not to exploit special knowledge about the implementation of the queue just in case the designer later decides to change the implementation of the queue object. For example, the designer may decide to use a linked list to store the private data rather than an array of characters. This change, however, should not affect the modules using the object because they only access the queue through its interface. As long as the queue interface remains the same, the designer is free to change the implementation without risk to the other modules using the object. This flexibility is a major advantage which encapsulation gives to the object oriented paradigm. Designs which incorporate encapsulation are much more maintainable than comparable designs which do not separate the interface from the implementation.