![](https://csdnimg.cn/release/download_crawler_static/1453242/bg11.jpg)
Functions are reusable. Once defined, they can be called any number of times without again
considering the implementation. The most generally useful functions can be collected in libraries
and reused in many different applications. All the user needs is the function interface, not the
source code.
However, unlike data elements, functions aren’t partitioned into separate name spaces. Each
function must have a unique name. Although the function may be reusable, its name is not.
C structures and functions are able to express significant abstractions, but they maintain the distinction
between data and operations on data. In a procedural programming language, the highest units of
abstraction still live on one side or the other of the data-versus-operations divide. The programs you
design must always reflect, at the highest level, the way the computer works.
Object-oriented programming languages don’ t lose any of the virtues of structures and functions—they
go a step further and add a unit capable of abstraction at a higher level, a unit that hides the interaction
between a function and its data.
Suppose, for example, that you have a group of functions that act on a particular data structure. You
want to make those functions easier to use by, as far as possible, taking the structure out of the interface.
So you supply a few additional functions to manage the data. All the work of manipulating the data
structure—allocating it, initializing it, getting information from it, modifying values within it, keeping
it up to date, and freeing it—is done through the functions. All the user does is call the functions and
pass the structure to them.
With these changes, the structure has become an opaque token that other programmers never need
to look inside. They can concentrate on what the functions do, not how the data is organized. You’ve
taken the first step toward creating an object.
The next step is to give this idea support in the programming language and completely hide the data
structure so that it doesn’t even have to be passed between the functions. The data becomes an internal
implementation detail; all that’s exported to users is a functional interface. Because objects completely
encapsulate their data (hide it), users can think of them solely in terms of their behavior.
With this step, the interface to the functions has become much simpler. Callers don’t need to know
how they’re implemented (what data they use). It’s fair now to call this an “object.”
The hidden data structure unites all the functions that share access to it. So, an object is more than a
collection of random functions; it’s a bundle of related behaviors that are supported by shared data.
To use a function that belongs to an object, you first create the object (thus giving it its internal data
structure), then tell the object which function it should perform. You begin to think in terms of what
the object does, rather than in terms of the individual functions.
This progression from thinking about functions and data structures to thinking about object behaviors
is the essence of learning object-oriented programming. It may seem unfamiliar at first, but as you
gain experience with object-oriented programming, you find it’s a more natural way to think about
things. Everyday programming terminology is replete with analogies to real-world objects of various
kinds—lists, containers, tables, controllers, even managers. Implementing such things as programming
objects merely extends the analogy in a natural way.
A programming language can be judged by the kinds of abstractions that it enables you to encode.
You shouldn’t be distracted by extraneous matters or forced to express yourself using a vocabulary
that doesn’t match the reality you’re trying to capture.
Interface and Implementation 17
2006-12-05 | © 2006 Apple Computer, Inc. All Rights Reserved.
CHAPTER 2
Object-Oriented Programming