Course 287: Lecture 6 Procedural and Data Abstraction: Object Orientation



Abelson and Sussman

Chapter 1 of Abelson and Sussman is entitled "Building Abstractions with Procedures". Chapter 2 of Abelson and Sussman is entitled "Building Abstractions with Data". We shall discuss many of the ideas covered in these chapters during the course, but not in exactly the same order. You will find a discussion of Data Abstraction in section 2.1 of Ableson and Sussmann (p83 ff.) See also section 1.1.8 Procedures as Black Box Abstractions (p26 ff.).

The need for abstraction

In abstraction we draw out (from the Latin verb traho I pull (c.f. tractor), and the preposition ab meaning "from" or "away from") an essential aspect of an idea, allowing it to be applied to more than the particular set of circumstances in which we first encountered it. We have already seen this at work when we considered the sum function and abstracted it to obtain the reduce function.

An important principle in the design of computational systems is to provide a measure of isolation of the implementation of a capability from its users. Thus a user is required to employ some kind of standard interface in accessing a capability. In doing this we are abstracting the essence of the capability from the point of view of its users.

For example, in computer hardware, a standard bus such as the VME bus can be used to connect modules. In operating systems, access to backing store is mediated via system-calls.

This isolation offers two primary advantages:

Sometimes a mechanism is provided to police the safety features. For example in the Unix operating system, it is impossible for a user program to issue an input-output instruction to access the disc directly. Any such instruction will be trapped by the machine hardware and referred to the kernel of the OS. On the other hand, in the DOS operating system, there is no such protection, so that correct usage of the disc is dependent on programmer discipline.

Likewise, in the Scheme language, any access to the machine's store is mediated by the car,cdr and cons functions. This prevents certain kinds of illegality from occurring. For example it is impossible in a Scheme system for a piece of store to be regarded as free when in fact it forms part of a user's data-structure.

By contrast, in the C language, the user has free access to her entire virtual machine, so that it is possible for a piece of store to be used in two contradictory ways by a single program.

However there is often a performance penalty associated with using a standard interface. During the evolution of computer hardware, many bus-standards have become obsolete as technology has advanced. For example, memory is now supplied as SIMM's which plug directly into a processor board. Likewise the writers of computer games are notorious for employing direct access to graphics hardware, rather than employing the standard interface, in order to achieve the necessary speed.

Likewise, the use of the car,cdr and cons functions in Scheme may carry a performance penalty compared with the more direct access offered by C. Not all storage configurations that can be created by C can be created by Scheme. Moreover the storage integrity demanded by Scheme can require that these primitive functions perform a check that the car and cdr functions are being applied to lists. The issue of efficiency is a complex one, and does not always imply that languages like Scheme are more inefficient than C, especially for large programs. So