The first general-purpose object-oriented language was SmallTalk, developed at Xerox PARC in the 1970s (the standard reference is SmallTalk-80).
Why should systems programmers care about object-oriented programming? It's not just that more and more systems code is written in object-oriented languages, such as C++.
What is now known as object-oriented design predates modern object-oriented languages, because of the two key benefits this style of programming offers:
- Program values that have state and can respond to and send messages (i.e., objects, are a natural mechanism when modelling or simulating real-world objects and processes.
- Objects that respond to messages support a kind of generic programming in which a range of disparate objects that support a common protocol can be treated uniformly, even if they that have completely different implementations of the behaviors in the protocol.
The motivation is easy to understand. An operating system like Unix or Linux that would like to run in a wide variety of hardware configurations should expect to support many different file systems, including a quite a few different hard disk systems (each with their own controllers), CDs, DVDs, USB drive, tape drives, etc. Even within a hardware configuration there may be different file systems structures, for example, a Linux can mount Windows file systems, file systems on RAIDs, log-based file systems, and the list goes on.
When a program opens a file or reads from a file, the kernel has to perform the operation on the program's behalf. The idea that the kernel should know about the details of every possible file system would make any developer cry in despair. Rather than perfrom the impossible, the kernel insists that every file system provide a data structure with common components and with implementations of a set of file system operations. When a program opens a file, say, the kernel finds out what file system the directory is in, then asks that file system to open the file and return a standard data structure. A file system is then a data value with state and behavior that obeys a particular protocol so that the kernel can perform generic file system operations — it's an object!
Before delving into the details of a file system, it's worth seeing object-oriented idioms in a simpler context. C is not an object-oriented language, of course, so there is no particular linguistic support for this paradigm. However, as you will see, the mechanisms underlying the basic elements of object orientation are not terribly complicated. You will also gain a better understanding of what Java and C++ are doing.
What's an object?
An object is a data value with state and behaviors. An object's state is represented as data values stored in the object. A heterogeneous collection of data values is astruct in C.
Behaviors are implemented as methods in Java and C++. Behaviors are implemented as functions in C. The main difference between a function and a method is that method is associated with an object. (In fact, in JavaScript, that's what a method is: a function associated with an object.)
C uses structs to hold aggregate data. So the state
of an object are fields in a structure. Fields can also hold pointers
to functions. So the simplest way to represent an object is to make a
struct that contains fields for all the state variables
(instance variables) of the object and for all the methods.
For example, one could create a object to represent a point with integer X- and Y-coordinates
to be continued...
Modified: 6 March 2008