Procedural and Object-Oriented Programming - Practices

Historically, procedural programming is the way almost all programs have been written. To create a procedural programming solution to a problem, you focus on the process that your program must implement to solve the problem. A rough outline of what you do, once the requirements have been defined precisely, is as follows:

• You create a clear, high-level definition of the overall process that your program will implement.

• You segment the overall process into workable units of computation that are, as much as possible, self-contained. These will usually correspond to functions.

• You break down the logic and the work that each unit of computation is to do into a detailed sequence of actions. This is likely to be down to a level corresponding to programming language statements.

• You code the functions in terms of processing basic types of data: numerical data, single characters, and character strings.

Apart from the common requirement of starting out with a clear specification of what the problem is, the object-oriented approach to solving the same problem is quite different:

• From the problem specification, you determine what types of objects the problem is concerned with. For example, if your program deals with baseball players, you’re likely to identify BaseballPlayer as one of the types of data your program will work with. If your program is an accounting package, you may well want to define objects of type Account and type Transaction. You also identify the set of operations that the program will need to carry out on each type of object. This will result in a set of application-specific data types that you will use in writing your program.

• You produce a detailed design for each of the new data types that your problem requires, including the operations that can be carried out with each object type.

• You express the logic of the program in terms of the new data types you’ve defined and the kinds of operations they allow.

The program code for an object-oriented solution to a problem will be completely unlike that for a procedural solution and almost certainly easier to understand. It will certainly be a lot easier to maintain. The amount of design time required for an object-oriented solution tends to be greater than for a procedural solution. However, the coding and testing phase of an object-oriented program tends to be shorter and less troublesome, so the overall development time is likely to be roughly the same in either case.

Let’s try to get an inkling of what an objected-oriented approach implies. Suppose that you’re implementing a program that deals with boxes of various kinds. A feasible requirement of such a program would be to package several smaller boxes inside another, larger box. In a procedural program, you would need to store the length, width, and height of each box in a separate group of variables. The dimensions of a new box that could contain several other boxes would need to be calculated explicitly in terms of the dimensions of each of the contained boxes, according to whatever rules you had defined for packaging a set of boxes.

An object-oriented solution might involve first defining a Box data type. This would enable you to create variables that can reference objects of type Box and, of course, create Box objects. You could then define an operation that would add two Box objects together and produce a new Box object that could contain the first two. Using this operation, you could write statements like this:

bigBox = box1 + box2 + box3;

In this context the + operation means much more than simple addition. The + operator applied to numerical values will work exactly as before, but for Box objects it has a special meaning. Each of the variables in this statement is of type Box. The preceding statement would create a new Box object big enough to contain box1, as well as box2 and box3.

Being able to write statements like this is clearly much easier than having to deal with all the box dimensions separately, and the more complex the operations on boxes you take on, the greater the advantage is going to be. This is a trivial illustration, though, and there’s a great deal more to the power of objects than that you can see here. The purpose of this discussion is just to give you an idea of how readily problems solved using an object-oriented approach can be understood. Object-oriented programming is essentially about solving problems in terms of the entities to which the problems relates rather than in terms of the entities that computers are happy with— numbers and characters. You’ll explore object-oriented programming in C++ fully starting in Chapter 11.

This chapter’s content has been broad-brush to give you a feel for some of the general concepts of C++. You’ll encounter everything discussed in this chapter again, and in much more detail, in subsequent chapters. However, some of the basics that this chapter covered are as follows:

• A program in C++ consists of at least one function, which is called main().

• The executable part of a function is made up of statements contained between a pair of braces.

• A pair of curly braces is used to enclose a statement block.

• In C++, a statement is terminated by a semicolon.

• Keywords are a set of reserved words that have specific meanings in C++. No entity in your program can have a name that coincides with any of the keywords in the language.

• A C++ program will be contained in one or more files.

• The code defining functions is usually stored in files with the extension .cpp.

• The code that defines your own data types is usually kept in header files with the extension .h.

• The C++ standard library provides an extensive range of capabilities that supports and extends the C++ language.

• Input and output in C++ are performed using streams and involve the use of the insertion and extraction operators, << and >>.

• Object-oriented programming involves defining new data types specific to your problem. Once you’ve defined the data types that you need, a program can be written in terms of the new data types.

The following exercises enable you to try out what you’ve learned in this chapter. If you get stuck, look back over the chapter for help. If you’re still stuck after that, you can download the solutions from the Apress website (http://www.apress.com/book/ download.html), but that really should be a last resort.

Exercise 1-1. Create a program that will display the text "Hello World" on your screen.

Exercise 1-2. Change your program so that it uses the hexadecimal values of the characters to spell out the phrase. If you’re working on a computer that uses ASCII to encode its characters, you’ll find a table of the values you need in Appendix A. (Hint: When you’re using hexadecimal ASCII values, "He" can be displayed by the statement std::cout << "\x48\x65";.)

Exercise 1-3. The following program produces several compiler errors. Find these errors and correct them so the program can compile cleanly and run.

 #include <iostream>>
 using namespace std;
 int main() {
  cout << endl
       << "Hello World"
       << endl
 return0;
)

Exercise 1-4. What will happen if you remove the using directive from the program in Exercise 1-3? Apart from restoring the using directive, how else could you fix the problem that occurs? Why is your solution better that restoring the original using directive?

This article is excerpted from Beginning ANSI C++ The Complete Language by Ivor Horton (Apress, 2004; ISBN  1590592271). Check it out at your favorite bookstore today. Buy this book now.