Chapter 7: Identifying and Describing Objects

Object-oriented programming is as easy a playing a game of Password. Fans of the Game Show Network remember the popular game where a player identifies something to another player by describing it. Try playing Password the next time your party hits a lull and you ll see how easy it is ”or isn t ”to describe something. What does the game Password have to do with object-oriented programming? Both require you to identify an object by describing it. A Password player describes an object to a fellow player, whereas a programmer describes an object to a program in the form of a class definition. Describing an object is a deceivingly simply concept to understand, but one that is difficult to do. We ll show you how the pros do it in this chapter.

An Object

The world would be a difficult place in which to live if we only described things based on their attributes and behaviors like we do when playing the game Password. Think for a moment. How would you describe yourself as a student without using the word student ? It wouldn t be easy because we don t look at the world as descriptions of things. Instead, everything in our world is viewed as an object.

If someone asks, What do you do? You probably reply by saying you are a student. No further explanation is needed because everyone knows the characteristics of a student. They know you are low on funds, pay tuition, attend classes, do homework, and go to all-night parties to break the tension.

If someone asks, How do you go to school? You probably say that you drive a car. Again, no further explanation is required. Everyone knows what a car is. You don t need to go into a lengthy descriptions of the car you drive.

As you learned at the beginning of this book, object-oriented programming is centered on identifying and describing real-world objects so they can be used by a program the same way that we use objects in real life. Throughout this book you learned how to create objects in C++ and Java programs by defining classes and then declaring instances of those classes in your programs.

We ll switch gears a bit in this chapter and explore techniques object-oriented programmers use to identify and describe real-world objects so that those objects can be encoded into an object-oriented program. Once you ve mastered these techniques, you ll be able to translate an object you see around you into one or more classes in your program.

Let s begin our exploration with the definition of an object. An object is a person, place, or thing ”such as a student, a campus, or a book ”that is defined by an object name , attributes, and behaviors.

An object name is the name of an object, such as student, campus, or book. An attribute is information about the object, such as a student name (Bob Smith), the name of a campus (Morningside Heights campus), or the title of a book (Object-Oriented Programming Demystified). A behavior is an activity that is associated with an object. For example, a student registers for class. The campus is open or closed. And the book can be opened or closed.

Identifying Attributes

Some attributes are easy to identify because we use them to describe an object. For example, attributes of a student object are the student s name, home address, home telephone number, and personal e-mail address. You probably can think of other attributes that describe a student.

Other attributes are not obvious. Let s say you are identifying attributes of a window. You are likely to mention the height, length, and width of the window and maybe the color of the window frame. However, you also need to identify the opaqueness of glass and other finer attributes that the average person overlooks when seeing a window. Admittedly you can find yourself going crazy trying to identify all attributes of an object because there are so many of them in a typical object.

Object-oriented programmers determine the number and type of attributes that they need to identify based on the goals of the system they are developing. For example, a college admission system contains a student object. This system needs a set of attributes that identifies a student, provides student contact information, the student s academic record, and recommendations. The system doesn t need the student s complete medical history, psychological profile, or genealogical background.

In contrast, a system that simulates a window, such as a Computer Aided Design application, needs to have sufficient attributes of a window in order to project how the window reacts to different circumstances. For example, the tensile strength of the window is needed in order to depict how the window reacts to hurricanes. Tensile strength is an attribute that is an indicator of how much pressure the window can withstand before breaking.

Therefore, you should determine the needs of your system before embarking on identifying attributes of objects that will be used by your system. Limit your selection of attributes to only those attributes your system requires. This ensures that you spend your time efficiently and identify only the attributes of an object needed by your system.

Describing Attributes

Identifying the proper set of attributes for your system is half the job. You still need to describe each attribute. Think of identifying an attribute as naming the attribute, and think of describing an attribute as assigning the attribute name a value.

Some descriptions are intuitive, such as using inches to describe the height of a window. Other descriptions are more challenging. For example, how would you describe the color of a window? You might say, the window is white, blue, black, or the name of any color. However, those colors are vague because each of those colors has a hundred or more shades. When you say that the window is blue, you really mean that the window is one of many shades of blue.

Attributes that have subjective values are difficult to describe because the system that you develop requires precise values and not subjective values. Fortunately, there are standard ways of precisely defining subjective values of many attributes. It is your job to learn those standards before you begin identifying attributes. Typically, the business unit who is sponsoring your system can provide you with those standards.

For example, several standards are used to precisely define a color as a unique number. You would use the standard that is appropriate for your system to describe the color attribute of an object.

Decomposing Attributes to Data

Some programmers who are not familiar with object-oriented programming confuse attributes of an object with data associated with an object. Previously you learned that an attribute is information that describes an object. Data is the smallest amount of meaningful information.

This sounds confusing at first, but an example will quickly make this clear. At attribute of a student object is the student s name. However, the student s name isn t the smallest amount of meaningful information. The smallest amount of information is the student s first name, middle name, and last name, each of which is called data .

Object-oriented programmers decompose each attribute into data and then use data in the corresponding class definition to describe the object. Decomposition is the technique that reduces an attribute into its data components .

The best way to decompose attributes is to make a two-column list, as show in Table 7-1. List the attribute in the first column and then ask yourself whether the attribute is the smallest amount of meaningful information that describes the object.

Table 7-1: Decomposing Attributes to Data



Student Name

First Name


Middle Name


Last Name

Student Address

Street Address 1


Street Address 2






Zip Code



If so, then use the attribute as data. For example, the attribute Graduated, shown at the bottom of Table 7-1, is the smallest amount of meaningful information. It cannot be decomposed. Therefore, the attribute is data and is listed in the data column.

If the attribute is not the smallest amount of meaningful information, then decompose (break down) the attribute into its data components. Table 7-1 illustrates the decomposition of the Student Name and Student Address attributes.

Identifying Behaviors

A behavior of an object is something an object does. Some behaviors are obvious and easy to identify, such as a student registering for a course. Other behaviors are less obvious and can be illusive to identify, such as how a window behaves when the full force of a hurricane bears down on the window glass.

You can imagine that an object performs hundreds of behaviors. However, you don t need to identify all of them. Instead, you need to identify behaviors that are relative to the goal of your system. Let s say you are writing a Computer Aided Design application that is used to design a house. One of the objects you ll need is a window. The application shows how the window looks when installed in the house. Therefore, you only need to include two behaviors: open the window and close the window. You don t need to include how the window behaves in a hurricane because the application doesn t simulate the structural behavior of a window.

Object-oriented programmers identify behaviors of an object by brainstorming. They begin by creating a two-column table, as shown in Table 7-2, and enter the name of each object in the first column. Next, they asked themselves , What does the object do in relation to the nature of the system that is being developed? Answers are behaviors and are listed in the second column.

Table 7-2: Identifying Behaviors of an Object




Register for course


Drop course


Take exam


Select major


Change major

Table 7-2 contains just a few behaviors that are associated with a student. You can easily expand upon this list.

Describing Behaviors

Once you identify all the behaviors of an object that are needed by your application, you must describe each behavior in detail. The description of a behavior consists of data needed to perform the behavior, the steps to perform, and the data that is a result of performing the behavior, if there is any.

This should sound familiar to you. The description of a behavior is nearly identical to the definition of a function (method in Java). When you define a function, you need to identify the data needed to perform the function (arguments). You also need to define steps required to perform the function (body of the function), and you need to define the data that is returned after those steps are completed (return value).

There is a subtle difference between describing a behavior and defining a function. When describing a behavior, object-oriented programmers use a processing model diagram to illustrate the details of how the behavior is performed. The processing model diagram is then translated into pseudo code , which is a combination of English and a programming language that describes every detail of the processing model diagram. Pseudo code makes it easy for a programmer to encode the behavior into a program.

When a function is defined, the programmer uses C++, Java, or another programming language to define the details of how the function is to perform.

Processing Model

A processing model is shown in a diagram that describes how a behavior is performed. The diagram is built using symbols to represent aspects of the process. Figure 7-1 contains commonly used symbols that object-oriented programmers use to describe a processing model. You probably recognize these as flow chart symbols.

click to expand
Figure 7-1: Symbols used to create a processing model

The processing model diagram is a flow chart that provides both an iconic description and textual description of a process. An iconic description is a picture of the process, whereas a textual description describes the process in words.

A symbol conveys a common step in the process, such as displaying a prompt on the screen or receiving input from the user of the system. Most systems have these common steps. Within the symbol is textual information that provides information specific to the system being described. For example, textual information in the display symbol describes the flavor of information that is displayed on the screen. Likewise, textual information in the input symbol describes the kind of information entered into the system by the user .

Any process can be described in detail by arranging these symbols into a processing flow that complements the processing that you want to describe. Let s say that you want to describe the process used by a student to enroll in a course. Here s how this process works.

First, the system prompts the student to enter the course number. After the student enters the course number, the system determines whether the course is open. If it is, then information about the student is enrolled in the course by placing the student s information in the appropriate database file. A conformation notice is then displayed on the screen. If the course is closed, a message is displayed on the screen informing the student that the course is closed.

Figure 7-2 shows the processing model diagram that describes this process. Notice that the diagram uses symbols rather than text to describe each step. The first step shows the display symbol followed by the input symbol. Anyone who reads the diagram is expected to know the meaning of those symbols because they are used in practically all processing model diagrams.

click to expand
Figure 7-2: A processing model that illustrates how a student registers for a course

Within each symbol is text that provides information specific to each step. For example, the first step has the text Prompt student for course number. This tells the reader of the processing model diagram the nature of text that is displayed on the screen during that step. You don t need to enter the complete text in the symbol, but just enough information to give the reader an idea what is being displayed at that moment in the process.

Figure 7-2 is just one of many processing model diagrams used to describe the details of an application. There could be hundreds of such diagrams that are connected together to describe the entire application. For example, the process shown in Figure 7-2 links to two other processes ”a process to determine whether the course is open and another process that enrolls the student in the course. Each of these processes is represented in a rectangle in the diagram. The programmer must review the corresponding processing model diagram for each of these processes to determine the details on how they work.

Each process has a starting point and at least one termination point. There can be multiple termination points if the process takes different paths, depending on the results of evaluating a condition, as is the case in Figure 7-2. This process takes one of two paths, depending on whether the course is open or closed. Each path has its own termination point.

Each step of the process, as pictured by the symbols in the processing model diagram, must connect to a previous step and to the next step in the process, as illustrated in Figure 7-2. Arrows are used to connect each step and show the processing flow. Although the process in Figure 7-2 flows downward, processes can flow to previous steps. For example, a step might test a condition. If the condition is true, then other steps are processed afterward and the process returns to test the condition again. This process should sound familiar to you because it is the process used in a loop.

Pseudo Code

Some programmers begin coding an application by using information contained in the processing model diagram. Other programmers translate the processing model diagram into pseudo code. Previously in this chapter you learned that pseudo code is a combination of English words and programming language syntax that describe in words how a process works.

The following example is the pseudo code translation of the processing model diagram shown in Figure 7-2:

 Prompt student to enter a course number 
Read the course number
Determine if the course is open or closed
If the course is open
Enroll the student
Store the student's information into the course file
Display enrollment confirmation on the screen.
Display a message telling the student that the course is closed
end if

You can easily pick out English sentences from programming syntax and yet you don t have to be trained in programming to understand the process described in the pseudo code. Anyone can read the pseudo code under the process.

Pseudo code does more than describe a process. It also organizes steps into the logical sequence that the program must follow. This enables a programmer to focus on translating pseudo code into programming syntax, sometimes by simply replacing each step in pseudo code with the corresponding statement(s) of a programming language that is needed to perform the step.

OOP Demystified
OOP Demystified
ISBN: 0072253630
EAN: 2147483647
Year: 2006
Pages: 130

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: