
	Department of Mathematics and Computer Science

[Return to Math 169 Homepage]

Math 169 Notes -- Data Encapsulation and Object-Oriented Programming

A. Data Encapsulation
B. Object Oriented Programming Overview
C. OOP History
D. Other OOP-Related Concepts
E. Miscellaneous

A. Data Encapsulation

Disatisfaction with (perceived) deficiencies in languages, coupled with the desire for specific improvements and the prospect of significantly different types of hardware led, during the 1970s, to the development of the concept of DATA ENCAPSULATION.

Some considerations:

-- Fortran had only local variables (now MODULES have been introduced).
-- Pascal had global variables (and so does C), but too many global variable become unwieldy. Separate compilation in some languages is not standard.
-- Older languages could not immediately handle the possibility of parallel processors, i.e., different processors working on the same program at the same time.

The result was the creation of a way to encapsulate a large structure with its own special operations (e.g., a stack, with Push and Pop) and its own local variables as part of another language object. In the late 1970s and 1980s this was incarnated in Modula-II (successor to Pascal) as modules, in Ada (DOD Language) as packages, in Path-Pascal (developed at the Univ of Illinois) as objects.

NOTE: Path-Pascal also include the concept of a "path statement" which could specified the order in which local functions could be invoked and the maximum number of copies of the structure that could be active at any one time.

EXAMPLES

ADA
     PACKAGE REALSTACK IS
        TYPE STACK IS PRIVATE
	PROCEDURE PUSH(F:IN FLOAT; S:IN OUT STACK);
	PROCEDURE POP(F:OUT FLOAT; S:IN OUT STACK);
     END REALSTACK;

Advantages to the use of Data Encapsulation

Typical programs need to share program objects (such as data, functions, etc.) between several program segments. One can use global variables, but this can be dangerous. One can pass parameters, but this is often inefficient and cumbersome for complex, large, and numerous data.

We would like to be able to share variables as if we were using globals but without uncontrolled/unauthorized access,.

We also would like to include the ability to

-- restrict the name space (i.e., "hiding") from the rest of the code,
-- make the lifetimes of variables dependant on the lifetimes of the entire code, if desired,
-- include other aspects of "encapsulation."

Basically, we don't want unexpected sharing of data and code, but we want to preserve the benefits of global variables.

This is a crucial concern for software engineering projects, especially those with many programmers working together on a large project.

This had led to various features in recent languages, such as MODULES in Fortran-90, or packages in Ada. Such units can store data and functions/procedures/subroutines and the units can be accessed on a limited basis via a use or with statement. In some languages, the contents can be restricted with public or private labels.

The concern about data encapsulation led to developing a new paradigm for programming languages, data structures, and the way one designs a program.

B. Object-Oriented Programming Overview

Some concepts related to "Object-Oriented Programming" (OOP) date to the late 1960s and the language SIMULA (or SIMULA 67). Alan Kay at the University of Utah (1969) did work that led to SMALLTALK, considered to be "the" OOP language.

(Cf. article by P. Marquess in Dec Professional, March 1991.)

One definition of OOP is the following:

Objects + Classes + Inheritance = Object-Oriented

Object -- a run-time entity. This term can refer to anything from the integer 5 to a large simulation subroutine. A specific desk or dinosaur is an object (incarnated at this particular moment).
Class -- a template for an object, i.e., a blueprint, or compile-time entity. The concept of "deskness" or of certain types of "dinosaurs" constitutes a class, even though none may exist in reality until some moment of time during the running of a program. There are many biological classes of entities that are extinct. The classes (i.e., templates) are very real even though the object to which they refer do not exist.
Inheritance -- the ability for a class to make use of properties, etc., from an "ancestor" class.

Since OOP languages usually include "classes" or "modules" that contain both data and functions ("methods") and the ability to designate certain compoments as "public" or "private," OOP languages have included the basic concept of data encapsulation.

As an illustration, let us consider the common data structure of a stack. In older (non-OOP) languages, one would create the data storage structure (array or linked list) to store the information in the stack separately from the operations of Push, Pop, Peek used to interact and change the information. Thus, we might have:

         Information                  Operations

         Array/Linked List             Push
         Top of Stack Ptr              Pop
                                       Peek

In this model, it is easy to access the information directly and bypass the operations associated with the structure. In this model, information (data) and operations are separate and only linked by the way a programmer codes a program.

In an OOP Language, one would normally encapsulate the information and declare it PRIVATE, allowing access to it only via the related member operations. Thus, we might have:

                 CLASS: Stack

		Public:
		   Push (operation) 
		           has access to Array/Linked List
			   and Top of Stack Ptr (both private)
		   Pop (operation)
		           has access to Array/Linked List
			   and Top of Stack Ptr (both private)
	           Peek (operation)
		           has access to Array/Linked List
			   and Top of Stack Ptr (both private)

	      [Private:
	           Array/Linked List, Top of Stack Ptr ]
		   part of Class, but not accessible 
		   outside of Class

B. OOP History

Some suggest that OOP is a new revolution in programming, similar to the introduction of structured programming in the 1960s-1970s.

One problem is that OOP requires a new approach to programming. One is concerned with objects and what they are (which is usually more than just data), rather than procedures and what they do.

OOP requires a different approach to thinking about programs than with classical procedural languages. OOP also presents programmers with new problems and challenges!

Mere existence of OOP languages will not produce good OOP code.
For example, many people, accustomed to writing with GOTO's in BASIC or FORTRAN, initially try to use GOTO's in Pascal and C, and ignored the structures (e.g., case/switch, while, repeat, do, for) the new languages contain. Merely using Pascal or C doesn't automatically lead to good, structured code.
Stroustrup (author of C++) commented: "The better one knows C, the harder it seems to avoid writing C++ in C style, and thereby the easier it is to lose some potential benefits of C++."

The hope of OOP advocates is that OOP will lead to easily re-usable code.

Some purists insist that the only real OOP language is Smalltalk. Thus one can be fooled into thinking one understands OOP when using C++ or Java, since these languages are based on C, a procedural language.

Some say that one can understand Java better if one begins with Smalltalk and introduces the syntax of C rather than starting with C and introduces some OOP concepts. With Smalltalk, everything is an object and communicates with other objects via methods (i.e., member functions). This is not the way one normally thinks of C/C++. Older languages tend to separate data from functions. OOP languages start with an OBJECT which contains both information (data) and activity (functions) united together.

D. Other OOP-Related Concepts

There are other words used in OOP-circles. Some of them include:

Encapsulation -- already discussed earlier. This refers to the ability to protect data within classes/objects, even designating the data as "private," that is unable to be accessed from outside the class/object.
Modularity -- code that is written in sections that can be tested independently and then pieced together to create a larger program.
Automatic Memory Management (Garbage Collection) -- Necessary/helpful when objects are created and destroyed.
Multiple Inheritance -- the ability for an object or a class to inherit from more than one related superclass.
Polymorphisms -- The ability for an operator or procedure/function to be defined differently for different types of operands/arguments. It "adjusts" its meaning accordingly and can be considered to have different/many meanings ("poly" -- many, "morph" -- form). It is related to overloading of operators and "generic" functions.
Messages -- Objects communicate with each other via messages. Messages are used to request an operation that the object or another object can provide. "Messages" are part of the standard vocabulary of Smalltalk.

E. Miscellaneous

When should one use an OOP Language? Advocates might say, always! They justify their answer by arguing that it is difficult to separate physical objects from how they are used and so one should try to model this interconnection as much as possible in any program.

Others argue that many types of programming problems are not suited to the OOP paradigm and that forcing such a paradigm on, for example, a solution of a matrix-vector equation, may actually complicate matters considerably.

The best approach is to use a language which is appropriate to a problem in a way that uses the best features of a language and makes the solution of a problem as clear as possible.