Object-Oriented Software Development

Have you ever wondered why some organizations refer to the group responsible for computers and information systems as “data processing”?

1. Structured programming and structured design (which grew out of structured programming) understand the mission of software as that of processing data.
2. Structured programming and structured design are focused on the changes programs make in transforming input data to output data, seeing computer programs as action-oriented.

The early name of the computer programming profession—data processing—reflects this procedural perspective.

Object-oriented programming and design emphasize the view that software systems model the real world. 

Objects within an object-oriented system may still transform input data to output data, but this is not the only possible way to organize an object-oriented program.

From an object-oriented perspective, the group responsible for computers and information systems might aptly be named the Business Object Portfolio (BOP) group. Their function, is to assemble and maintain a portfolio of objects that model their organization’s processes.
If  you’re therefore less than enthusiastic about the prospect of being called a BOPper, never fear. You can choose to work in the health care industry, in which case you may come to be known HOPper (for “Health care Object Portfolio”) or
MOPper (for “Medical Object Portfolio”). That’s decidedly better than working in law enforcement, where you might come to be known as a COPper (for “Crime Object Portfolio”), or working in agriculture, where you might come to be known as a CROPper (for “Crop Rotation Object Portfolio”).


                            Procedural Programs

Computer programs, whether designed based on structured design or object-oriented design, usually model some process that exists in the real world.
A payroll program, for example, models the manual process that a real business goes through when it pays its employees. In a small business, the process might work something like this:

1. Get the list of employees from the file over by the coffee machine.
2. Get the federal and state withholding schedules out of the bottom right drawer of the desk.
3. Get the general ledger from the supervisor’s office.
4. For each employee on the list, do the following:
5.   (4.1). Get the amount of pay from the employee record.
6.   (4.2).  Calculate the amount of taxes due, based on the  withholding schedules.
7.   (4.3). Calculate the net pay by subtracting the deductions and withholding from the gross pay.
8.   (4.4). Prepare the check.
9.   (4.5). Record the check in the general ledger.
10. (5). Take the stack of checks to the boss to be signed.
11. (6). Mail the checks at the post office.
12. (7). Return the general ledger, withholding schedules, and list of employees to their regular places.

Most of these operations could be performed by a computer, though the computer wouldn’t do them exactly the same way the payroll clerk would.

1. When written as part of a computer program, the steps necessary to carry out a task are called a process. 
2. Each step within a process is known as a procedure. 
3. When a procedure is long or complex, it may consist of several steps, called subprocedures or simply procedures.
4. Procedures are the blocks used to build structured programs.

A typical payroll program, for example, would contain procedures to

• open and read the files, 
• perform the payroll calculations, and 
• print the checks.
• By using direct deposit, the program might even “sign” and “mail” the checks.

A procedural payroll program is structured like

Each of the boxes in Figure represents a procedure that carries out a series of steps.
Each procedure

1. receives input data, 
2. processes the data, and 
3. transmits the results of its processing, either to a subsequent procedure or to a human.

Data is fed to the procedures in much the same way that raw materials are fed to an assembly line—except the procedures produce information rather than cars or toasters.

A useful property of structured programs is that the “shape” of the solution (that is, the program) closely models the shape of the problem. 

Each of the procedures of the structured program in Figure relates to one or more of the steps in the process for manually preparing payroll checks.

Structured programs are designed by means of procedural decomposition. 

Using procedural decomposition, a designer studies the problem and attempts to break it apart by identifying a series of actions that solve it.

When a designer is asked to automate an existing business process, the design process is often simple because procedural decomposition is easy to perform. The designer merely uses the steps of the manual process to identify the actions that the program must perform. Because these steps have successfully kept the business from devolving into chaos, using them as the basis for a computer program may be less risky that trying an entirely new series of steps.

Think again, though, about what would happen to the manual payroll process in your imaginary business if it grew to 20,000 employees instead of 20.

• The employee file could no longer be kept in the filing cabinet over by the coffee machine. 
• Fred, the part-time bookkeeper, could no longer finish his work each Tuesday afternoon. 
• And, most importantly, the boss, who previously signed every check and would likely notice if Ms.Smallie’s check had $1,000 written on it, instead of $100, could no longer sign each check personally—there simply wouldn’t be enough remaining time to properly watch over the business.

When businesses grow, they change their structure to handle the added complexity caused by their growth. Finance departments, vice-presidents, controllers, and auditors are added because the simple structure that worked fine for a 20-person company is no longer adequate.
Computer programs can suffer from a similar malady. The  procedural paradigm (paradigm is just a fancy word for pattern) works fine for automating routine office processes, like preparing payroll checks. But it fails to offer sufficient structure when applied to many other kinds of problems, such as simulations and interactive environments.

If you’ve been around a while, you might remember when the main job of computer programmers and designers was writing programs that solved “assembly-line” problems like

• payroll, 
• batch accounting, and 
• monthly invoicing.

Things are different today.

• Instead of being assigned to write a data-processing program to tally the month-end statements, a bank programmer is more likely to be responsible for writing code to control the ATM or the bank’s new World Wide Web site. 
• A programmer for a stock broker might design automatic trading programs instead of a simple client billing application.
• Such interactive or “reactive” programs are much more complex than traditional data-processing applications, because the flow of control is no longer linear. Data doesn’t come in at the start of the program, flow through a number of predefined procedures, and exit at the end, relaxed and refreshed. 
• In a reactive program, the procedure DoThingC() might be called first, second, last, or not at all—unlike the procedural program where DoThingC() always follows DoThingA() and DoThingB().

Look back at Figure What does it look like? A pyramid, right? The pyramid structure occurs because of the hierarchical nature of control in the program.
ReadEmployeeRecord() relies on the fact that ProcessPayroll() has already performed the OpenEmployeeFile() process. The data and the environment required by ReadEmployeeRecord() are available only because the OpenEmployeeFile() procedure has been called first.
If you attempt to write an interactive program that uses procedures as its basic building block, however, the program structure no longer resembles a neat pyramid. Instead, it begins to look like a dense web of interconnections.

If you remember your first programming class, this might set off a light bulb.

1. Before the advent of structured programming, back in the days of “iron men,” when “big-iron” was not merely metaphorical, computer programs were largely monolithic—they had no procedures at all. Thus, when a programmer needed to execute a piece of code in another part of the program, an unconditional branch was used; such branches were called gotos. As programs got larger, the typical path of program execution began to resemble a large web. Such code became known as spaghetti code, code that was difficult or impossible to understand and thus difficult or impossible to maintain, fix, or change. The underlying problem was that programs were organized as a collection of source statements. Too many “blocks” (that is, source statements) were required to build large programs. 
2. To solve this problem, structured programming introduced the procedure as a second, larger organizing unit. Source statements were used to build procedures, but procedures (not source statements) were used to build programs. Thus, the number of blocks required to build a program decreased, reducing the complexity of the program.

                  Object-Oriented Programs

Object-oriented programming attacks the complexity of today’s programs in a similar fashion. By grouping procedures into still larger organizing units called objects, programs require fewer blocks and are, therefore, simpler.

Studying object-oriented programming, it’s hard not to notice the fact that different folks have very different views when it comes to OOP.
Reading various OOP books and papers, it almost seems that people are talking about entirely different things.
When you finally cut through all the rhetoric, though, there are two points of view:

1. the revolutionary: The advocate of the revolutionary view loudly proclaims that OOP is so different from traditional programming that you have to learn programming over again from scratch.
2. the evolutionary: The evolutionists, in contrast, say that OOP is really just new packaging of old concepts. Perhaps there’s some truth, as well as some error, in each of these views.

The evolutionists are correct when they assert that it is possible to write clear, well-commented, understandable code in a procedural language, and that it is possible to write incomprehensible, unmaintainable code in an object-oriented language.
The evolutionist generally fails to recognize, however, that an OOP program is organized in a fundamentally different manner than a procedural program.

The revolutionist is right in pointing out that the OOP design process uses different tools and different types of abstraction, and that no amount of functional decomposition will ever yield an object-oriented program.
The revolutionist overestimates, perhaps, the value of such an object-oriented design when weighed against factors of clarity and understandability.

A well-designed and implemented procedural program is definitely to be preferred over a poorly conceived and written OOP program. OOP and object-oriented languages provide tools to express ideas clearly, but are not instant, automatic panaceas.

Five fundamental concepts govern object-oriented programs:

• Objects
• Classes
• Encapsulation
• Inheritance
• Polymorphism

                      What Are Objects?

Just as procedures are used to build structured programs, objects are used to build object-oriented programs.

An object-oriented program is a collection of objects that are organized for, and cooperate toward, the accomplishment of some goal. 

Every object:

• Contains data. The data stores information that describes the state of the object.
• Has a set of defined behaviors. These behaviors are the things that the object “knows” how to do and are triggered by sending the object a message. 
• Has an individual identity. This makes it possible to distinguish one object from another, just as it’s possible to distinguish one program variable from another.

Like the records or structures used in procedural programs, objects contain data. In this sense, an object looks very much like one of the employee records that would be used in the payroll program. An object’s data is used to represent the object’s state. For example, data within an employee object might indicate whether an employee is full-time or part-time, hourly or salaried.

Unlike the employee record within a procedural program, however, an employee object can also contain operations. These operations may be used to read or change the object’s data.

In this sense, an object acts like a small “mini-program” that carries its own data around on its back

If you want to do something to an object, or want to know something about it, you “ask it” to perform one of its operations. In object-oriented parlance, you send it a message.
In response, it performs some behavior.

The second characteristic of an object, then, is that it has some built-in behavior: An  employee object may know how to tell you its salary, or how to print itself out to a mailing-address label.

The third characteristic of an object is that every object has a unique identity. This doesn’t mean that every object necessarily has an ID number, or a “primary key” like you find in relational databases. Objects are very much like program variables in a procedural language. 

The integer variables i and j may have exactly the same value—say 3—and yet they are distinct variables, stored at different locations within the computer’s memory.
Changing the value of i to 4, for example, does not change the value of j.
Similarly, two employee objects that represent the identical twins who work in shipping, Fred and Ned, may have the same data contents, yet still be distinct objects.

Much, but not all, of the terminology used in object-oriented programming is the same from programming language to programming language. However, knowing about the differences in terminology might help you avoid some confusion when you find yourself “talking objects” to a Smalltalk or Object Pascal or C++ programmer.
In Java, the operations of an object or class are called methods, just as in Smalltalk.
C++ programmers call methods member functions.
While Smalltalk programmers always speak of sending a message, C++ programmers tend to refer to calling a member function.
Java programmers tend to split the difference, and speak either of  sending a message to an object, or calling an object’s method, depending on whether it is the sender or the recipient of the message that is the focus of discussion.




[to be continued...]