Handling Complexity - Data Abstraction Print E-mail
Wednesday, 31 January 2001 09:24
Article Index
Handling Complexity
Data Abstraction
Modularization
Encapsulation
All Pages

Data Abstraction

If you’ve ever written a large program based on a certain type of data, then you know what a pain it is to have to later alter the program to handle a different kind of data. That little change can mean having to rewrite the entire program with a whole new set of functions to handle the new data type.

But suppose you split up your original solution. First, you have some code that describes your data and its basic operations. Then you have your main code, which actually solves the problem, with any generic kind of data. With this kind of design, all you have to do to change the data type is to write code that describes the new data type; you’ll need to make few, if any, modifications to your main program.

Sorting algorithm


for each line of data in the input file
read the line of data
if there is no data in the output file
store the data in the output file
else
while the new data should come after the current output data
check the next data item in the output file
end while
insert the new data after the current data
end if-else
end for

Numeric-type data abstraction
- integer: value
- integer-compare-function()

String-type data abstraction
- string: value
- string-compare-function()

In the above pseudocode example, the sorting algorithm works no matter what kind of data you’re sorting. This principle of separating data from the code that manipulates it is called data abstraction, because the data is defined only abstractly in the main solution. It allows the programmer to focus on algorithms that handle generic data. Then the same program code can be used to manipulate many different kinds of data, as long as that data is separately defined with its simple functions that directly handle it.

An object is a self-contained entity that contains both data and the functions to manipulate that data. In object-oriented jargon, functions are called methods. The data is an essential part of the object because it describes the object’s state. (You could kind of think of the data as an object’s variables, except that OOP purists would castigate you for carrying over this archaic construct from static, iterative programming languages.) The methods are equally important, because they tell what the object can do with its data. (OOP methods are equivalent to subroutines, functions, and procedures in other languages.) An object’s data and methods are collectively called its members. The members of an object form a data abstraction.

Thus an object-oriented programmer can define objects that know what kind of data they have and know how to handle them. So when programmers write their main solution code, they don’t have to worry about the data type. And if the kind of data that the program needs should later change (as it always does), all a programmer needs to do is create new objects, and make minimal changes to the main program code.

 



Last Updated on Tuesday, 28 October 2008 13:42