|
|
|
In Object-Oriented terminology, collecting together a large group of
several thousand small "things" into one single
"thing" called an automobile is called encapsulation.
Once encapsulated, the individual components within an object are
dedicated to that one object. Humans have been classifying everything in their world into "Objects" since the dawn of history because it is our natural tendency to do so. By adapting our computer languages to Object-Oriented Concepts, we tap into this natural human tendency resulting in easy to use languages. |
class: Employee // top-level data: Name, Title: string PayRate: floating-point no. code: initialize // assign values for name, title, rate getname // print indicated info gettitle getrate getpayamount // calculate & print pay using rate class: Hourly Employee // subclass of employee data: time: integer; // inherits Name, Title, PayRate code: initialize // assign values for name, rate, title, time gettime getpayamount // other "gets" are inherited class: Salaried Employee // another subclass of Employee data: commission, // also inherits Employee data fields salesamount: floating-point no. code: initialize // assign values for name, rate, title, // commission, salesamount getcommission getsales getpayamount // again, other "gets" are inherited
| Every Western town has a few key ingredients:
stables, saloons, sheriffs, and a couple troublemakers. A standard
town would have three stables and be located West of the Mississippi
sometime around 1850.
|
This description of a Western town, while not very profound, did two important things: 1) It established the key ingredients for a Western Town and 2) It gave several values that might occur in a default Western Town. (Any more than three stables and the place starts to stink)
public class WesternTown
{
int stables;
int saloons;
int sheriffs;
int troublemakers;
String location;
int time;
public WesternTown()
{
stables = 3;
location = "Western America";
time = 1850;
}
}
|
This chapter is a short survey of programming techniques. We use a simple example to illustrate the particular properties and to point out their main ideas and problems.
Roughly speaking, we can distinguish the following learning curve of someone who learns program:
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 statements which modify data which is global throughout the whole program.
Figure 2.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 these procedures.
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.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
.
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
Figure 2.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 divided into several smaller parts which interact through procedure calls and which form the whole program
Figure 2.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 2.6: Object-oriented
programming. Objects of the program interact by sending messages to each other.
Object-Oriented
Programming
An
automobile is a very good example of the Object-Oriented
Concept. As humans, it is our natural tendency to think of an
automobile as a single "thing", and not as a large
group of several thousand small "things". Thinking of
the automobile as a single "thing" helps us deal with
the overwhelming complexity of the whole machine. We would say
simple statements like; "Fill her up." or "How
fast are we going?" or "I have a Blue car." ...
and everyone would understand how those statements apply to our
car.