Roughly speaking, we can distinguish the following learning curve of someone who learns to program:
- Unstructured programming,
- procedural programming,
- modular programming and
- object-oriented programming.
Usually, people start learning programming by writing small and simple programs consisting only of one main program. Here ``main program'' stands for a sequence of commands or statementswhich modify data which is global throughout the whole program. We can illustrate this as shown in Fig. 2.1.
Figure 1: Unstructured programming. The main program directly operates on global data.
 |
As you should all know, this programming techniques provide tremendous disadvantages once the program gets sufficiently large. For example, if the same statement sequence is needed at different locations within the program, the sequence must be copied. This has lead to the idea to extract these sequences, name them and offering a technique to call and return from theseprocedures.
With procedural programming you are able to combine returning sequences of statements into one single place. A procedure call is used to invoke the procedure. After the sequence is processed, flow of control proceeds right after the position where the call was made (Fig. 2.2).
Figure 2: Execution of procedures. After processing flow of controls proceed where the call was made.
 |
With introducing parameters as well as procedures of procedures ( subprocedures) programs can now be written more structured and error free. For example, if a procedure is correct, every time it is used it produces correct results. Consequently, in cases of errors you can narrow your search to those places which are not proven to be correct.
Now a program can be viewed as a sequence of procedure calls
![[*]](http://www.tiem.utk.edu/~gross/c++man/foot.gif)
. The main program is responsible to pass data to the individual calls, the data is processed by the procedures and, once the program has finished, the resulting data is presented. Thus, the
flow of data can be illustrated as a hierarchical graph, a
tree, as shown in Fig.
2.3 for a program with no subprocedures.
Figure 3: Procedural programming. The main program coordinates calls to procedures and hands over appropriate data as parameters.
 |
To sum up: Now we have a single program which is devided into small pieces called procedures. To enable usage of general procedures or groups of procedures also in other programs, they must be separately available. For that reason, modular programming allows grouping of procedures into modules.
With modular programming procedures of a common functionality are grouped together into separate modules. A program therefore no longer consists of only one single part. It is now devided into several smaller parts which interact through procedure calls and which form the whole program (Fig. 2.4).
Figure 4: Modular programming. The main program coordinates calls to procedures in separate modules and hands over appropriate data as parameters.
 |
Each module can have its own data. This allows each module to manage an internal state which is modified by calls to procedures of this module. However, there is only one state per module and each module exists at most once in the whole program.
Object-oriented programming solves some of the problems just mentioned. In contrast to the other techniques, we now have a web of interacting
objects, each house-keeping its own state (Fig.
2.6).
Figure 5: Object-oriented programming. Objects of the program interact by sending messages to each other.
 |
Consider the multiple lists example again. The problem here with modular programming is, that you must explicitly create and destroy your list handles. Then you use the procedures of the module to modify each of your handles.
In contrast to that, in object-oriented programming we would have as many list objects as needed. Instead of calling a procedure which we must provide with the correct list handle, we would directly send a message to the list object in question. Roughly speaking, each object implements its own module allowing for example many lists to coexist.
Each object is responsible to initialize and destroy itself correctly. Consequently, there is no longer the need to explicitly call a creation or termination procedure.
You might ask: So what? Isn't this just a more fancier modular programming technique? You were right, if this would be all about object-orientation. Fortunately, it is not. Beginning with the next chapters additional features of object-orientation are introduced which makes object-oriented programming to a new programming technique.
No comments:
Post a Comment