Classes
A program can have more than one object of the same kind. The program that models water usage, for example, might have several Faucets and Pipes and perhaps a handful of Appliances and Users. Objects of the same kind are said to be members of the same class . All members of a class are able to perform the same methods and have matching sets of instance variables. They also share a common definition; each kind of object is defined just once.
In this, objects are similar to C structures. Declaring a structure defines a type. For example, this declaration
struct key { |
char *word; |
int count; |
}; |
defines the struct key
type. Once defined, the structure name can be used to produce any number of instances of the type:
struct key a, b, c, d; |
struct key *p = malloc(sizeof(struct key) * MAXITEMS); |
The declaration is a template for a kind of structure, but it doesn’t create a structure that the program can use. It takes another step to allocate memory for an actual structure of that type, a step that can be repeated any number of times.
Similarly, defining an object creates a template for a kind of object. It defines a class of objects. The template can be used to produce any number of similar objects—instances of the class. For example, there would be a single definition of the Faucet class. Using this definition, a program could allocate as many Faucet instances as it needed.
A class definition is like a structure definition in that it lays out an arrangement of data elements (instance variables) that become part of every instance. Each instance has memory allocated for its own set of instance variables, which store values peculiar to the instance.
However, a class definition differs from a structure declaration in that it also defines methods that specify the behavior of class members. Every instance is characterized by its access to the methods defined for the class. Two objects with equivalent data structures but different methods would not belong to the same class.
In this section:
Modularity
To a C programmer, a “module” is nothing more than a file containing source code. Breaking a large (or even not-so-large) program into different files is a convenient way of splitting it into manageable pieces. Each piece can be worked on independently and compiled alone, then integrated with other pieces when the program is linked. Using the static
storage class designator to limit the scope of names to just the files where they’re declared enhances the independence of source modules.
This kind of module is a unit defined by the file system. It’s a container for source code, not a logical unit of the language. What goes into the container is up to each programmer. You can use them to group logically related parts of the code, but you don’t have to. Files are like the drawers of a dresser; you can put your socks in one drawer, underwear in another, and so on, or you can use another organizing scheme or simply choose to mix everything up.
Access to Methods: It’s convenient to think of methods as being part of an object, just as instance variables are. As in Figure 3-1 , methods can be diagrammed as surrounding the object’s instance variables. But, of course, methods aren’t grouped with instance variables in memory. Memory is allocated for the instance variables of each new object, but there’s no need to allocate memory for methods. All an instance needs is access to its methods, and all instances of the same class share access to the same set of methods. There’s only one copy of the methods in memory, no matter how many instances of the class are created.
Object-oriented programming languages support the use of file containers for source code, but they also add a logical module to the language—class definitions. As you’d expect, it’s often the case that each class is defined in its own source file—logical modules are matched to container modules.
In Objective-C, for example, it would be possible to define the part of the Valve class that interacts with Pipes in the same file that defines the Pipe class, thus creating a container module for Pipe-related code and splitting the Valve class into more than one file. The Valve class definition would still act as a modular unit within the construction of the program—it would still be a logical module—no matter how many files the source code was located in.
The mechanisms that make class definitions logical units of the language are discussed in some detail under “Mechanisms Of Abstraction” .
Reusability
A principal goal of object-oriented programming is to make the code you write as reusable as possible—to have it serve many different situations and applications—so that you can avoid reimplementing, even if only slightly differently, something that’s already been done.
Reusability is influenced by a variety of different factors, including:
-
How reliable and bug-free the code is
-
How clear the documentation is
-
How simple and straightforward the programming interface is
-
How efficiently the code performs its tasks
-
How full the feature set is
Clearly, these factors don’t apply just to the object model. They can be used to judge the reusability of any code—standard C functions as well as class definitions. Efficient and well-documented functions, for example, would be more reusable than undocumented and unreliable ones.
Nevertheless, a general comparison would show that class definitions lend themselves to reusable code in ways that functions do not. There are various things you can do to make functions more reusable—passing data as arguments rather than assuming specifically named global variables, for example. Even so, it turns out that only a small subset of functions can be generalized beyond the applications they were originally designed for. Their reusability is inherently limited in at least three ways:
-
Function names are global; each function must have a unique name (except for those declared
static). This makes it difficult to rely heavily on library code when building a complex system. The programming interface would be hard to learn and so extensive that it couldn’t easily capture significant generalizations.Classes, on the other hand, can share programming interfaces. When the same naming conventions are used over and over, a great deal of functionality can be packaged with a relatively small and easy-to-understand interface.
-
Functions are selected from a library one at a time. It’s up to programmers to pick and choose the individual functions they need.
In contrast, objects come as packages of functionality, not as individual methods and instance variables. They provide integrated services, so users of an object-oriented library won’t get bogged down piecing together their own solutions to a problem.
-
Functions are typically tied to particular kinds of data structures devised for a specific program. The interaction between data and function is an unavoidable part of the interface. A function is useful only to those who agree to use the same kind of data structures it accepts as arguments.
Because it hides its data, an object doesn’t have this problem. This is one of the principal reasons why classes can be reused more easily than functions.
An object’s data is protected and won’t be touched by any other part of the program. Methods can therefore trust its integrity. They can be sure that external access hasn’t put it in an illogical or untenable state. This makes an object data structure more reliable than one passed to a function, so methods can depend on it more. Reusable methods are consequently easier to write.
Moreover, because an object’s data is hidden, a class can be reimplemented to use a different data structure without affecting its interface. All programs that use the class can pick up the new version without changing any source code; no reprogramming is required.
Last updated: 2007-12-11
  |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |