Once again, imagine the vacation budget app. You might create two functions, spendDollars: and chargeForeignCurrency:, that track your spending and foreign currency conversion charges against budgets for different countries. Rather than hard-coding the data for all the countries in one budget, you might use a different budget (such as europeBudget and englandBudget) for each country, and then use a pointer to a budget variable. A pointer's value is a memory address — it refers directly to (or "points to") another value stored elsewhere in memory. Using this pointer, the functions can access different budgets depending on where you were (Europe or England), and the function would operate on the data for that country.

The budget data structure definition would look like the following (I omitted the function implementations):

typedef struct {

  float exchangeRate;
  double budget;
  double exchangeTransaction;
} budget;

void spendDollars (budget *theBudget, double dollars);
void chargeForeignCurrency (budget *theBudget,
                               double foreignCurrency);

The problem is that if you wanted to change the data structure struct, you would have to go out and find all the functions that used it and change them. Although in a program this small it would be simple (there are only two functions, after all), in a more complex program, there could be functions all over the place using the struct.

A class that provides the same functionality as the budget struct data structure and the functions that use it, spendDollars: and chargeForeignCurrency:, would look like this:

@interface

Budget : NSObject {

  float  exchangeRate;
  double budget;
  double exchangeTransaction;
}

- (void) spendDollars: (double) dollars ;
- (void) chargeForeignCurrency: (double) foreignCurrency;

@end

Data and functions are now both members of the object. You no longer need to track down all the functions that use a particular data structure and revise them. Object-oriented programming allows you to skate right by such headaches through encapsulation. You no longer use sets of global variables or data structures that you pass from one function to another as arguments. Instead, you use objects that have their own data and functions as members.

This encapsulation solves the problem of the widespread impact that changing a data structure may have. Only an object's methods that are packaged with the data can access or modify that data, although an object can — and often does — make its data available to other objects through its methods.

Variables are not accessible from every nook and cranny in your program — they're accessible only within the function in which they are declared (that is, within the braces). This is also referred to as being scoped to the function. You could also have braces (which define a block) within a function, in which case variables are scoped within that code block.

Instance variables are scoped to (accessible within) the code block they're in. This can be a function, a code block within a function, or, in this case, a class. It is this built-in scoping mechanism that allows an object to hide its data by essentially limiting who (or what) has access to it. But to provide flexibility, when it comes to a class (here come the Objective-C extensions to C again), you can actually explicitly set the scope to three different levels through the use of a compiler directive:

You may have started your coding in a single source file — perhaps MyFirstProgram.m and then moving on to Budget.m (for the vacation budget app) or YourApp.m. Although this works initially, it won't scale when you start to develop a real app. As your program gets larger, scrolling through a single file becomes more difficult. But there's a well-thought-out solution for that problem that just about everyone uses.

When I write even the simplest apps for the iPhone, I divide things into multiple files.

The source code for Objective-C classes is divided into two parts. One part is the interface, which provides the public view of the class. The @interface contains all the information necessary for someone to use the class. The other part of a class's source is the implementation. The @implementation contains the method definitions.

It's helpful to have some idea about how to name things in order to avoid having the compiler scream at you. Here are some areas you need to pay attention to:

As part of its extensions to C, Objective-C adds two built-in generic C types that you can use for objects.

id is a generic C type defined as a pointer to an object data structure, which you use to refer to any kind of object regardless of class. All objects, regardless of their instance variables or methods, are of type id. You use id when I explain protocols in Chapter 5 of this minibook. For now, just keep this in mind.

Similarly, nil is defined as a null object, an id with a value of 0.

The @interface compiler directive tells the compiler that you're declaring a new class. It's the first line in the first example in the previous section:

@interface Budget : NSObject {

Budget : NSObject declares the new class name and links it to its superclass.

: NSObject on the @interface line tells the compiler that the Budget class is an extension of the NSObject class — NSObject is the Budget class's superclass, in other words. Budget will inherit all the methods and instance variables of NSObject. This means that, for all practical purposes, even though you don't see them in your class declaration, Budget includes all the instance variables and all the methods that are in NSObject.

After starting to declare a new class, you tell the compiler about the various pieces of data you want to work with — the instance variables and methods.

In my (running) example, the following lines of code appear on the line after

@interface Budget : NSObject { :

  float  exchangeRate;
  double budget;
  double exchangeTransaction;
}

exchangeRate, budget, and exchangeTransaction are the instance variables for objects of class Budget.

The reason they're called instance variables is that when you create an object of the Budget class, you're creating an instance of the class, which means that for each object you create, you allocate some amount of memory for its variables (just as you do for the data structure). The instance variables here correspond to the ones you would have used in the struct (data structure):

Because budget, exchangeRate, and exchangeTransaction are declared in the class definition, every time a Budget object is created, it includes these three instance variables. So every object of class Budget has its own budget, exchangeRate, and exchangeTransaction. The closing brace tells the compiler you're done specifying the instance variables for Budget.

Keeping the focus on the running example, the following lines of code appear on the line after the brace (}):

- (void) createBudget: (double) aBudget
                withExchangeRate: (float) anExchangeRate;
- (void) spendDollars: (double) dollars ;
- (void) chargeForeignCurrency: (double) foreignCurrency;

In Objective-C, these lines of code are called method declarations. They make public the behavior that Budget has implemented — making it clear to the whole world that this is the kind of stuff any object of the Budget class can do.

Methods are like functions that return a value, and method declarations are like function prototypes in C or C++, (although they look different). A function prototype is a declaration of a function that omits the function body (its definition), but specifies its name so that you can start referring to the function in your code. Eventually you have to provide a function definition elsewhere in the program in order to actually use the function. The function prototype also specifies the data type (the kind of data, such as char, int, and float, to be stored in memory) of the function's arguments, and the data type of the value that the function returns.

Here is an example of a method declaration (from the preceding code):

- (void) spendDollars: (double) dollars;

The leading dash signals that this is the declaration for an Objective-C method. That's one way you can distinguish a method declaration from a function prototype, which has no leading dash.

Following the dash is the return type for the method, enclosed in parentheses — the value of what the method returns (similar to what a function returns). Methods can return the same types as functions, including standard types (int, float, and char), as well as references to other objects.

spendDollars: is a method that takes a single argument of type double. Notice that instead of the parentheses used in a function to indicate arguments, methods use a colon (:). Also notice that the colon is part of the method name.

Although the spendDollars method I came up with doesn't return a value, I could add that functionality at a moment's notice by doing just what you'd do if you were dealing with a function prototype — adding the following:

return someValue;

For all practical purposes, chargeForeignCurrency works the same way as spendDollars:

- (void) chargeForeignCurrency: (double) foreignCurrency;

Finally, you've come to the mind-numbing part — createBudget::.

- (void) createBudget: (double) aBudget
           withExchangeRate: (float) anExchangeRate;

The createBudget:: method initializes the values — the budget and exchangeRate — for an object that is the budget for a particular country. You might have coded this by assigning those values to the members in a struct data structure, as follows:

vacationBudgetEurope.exchangeRate = 1.2500;
vacationBudgetEurope.budget = 1000.00;
...
vacationBudgetEngland.exchangeRate = 1.5000;
vacationBudgetEngland.budget = 2000.00;

But because (as I explain in the earlier section "Scoping instance variables") you don't have access to the instance variables in a Budget object (say "encapsulation" three times and click your heels), you need to create a method to assign initial values to the instance variables. (Initialization is an important part of Objective-C, and I explain it in detail in Chapter 3 of this minibook.)

Although you might be able to guess that the method takes two arguments, the syntax of the declaration is probably not something you're familiar with. (Talk about a classic understatement.) Here goes:

- (void) createBudget: (double) aBudget
             withExchangeRate: (float) anExchangeRate;

When there's more than one argument, the aBudget and anExchangeRate argument names are declared within the method name after the colon. The full method name is createBudget:withExchangeRate:.

This does take some getting used to, but when you do, you'll like it a lot.

Because createBudget:: won't be returning anything, I used void to indicate that there's no return value.

The @end compiler directive does exactly what its name implies it's going to do: It tells the compiler that you've finished the interface declaration.

The complete interface for the Budget class is done. Now, anyone using this object knows that this class has three methods that can create a new budget, spend dollars, and charge something in a foreign currency: methods appropriately named createBudget:, spendDollars:, and chargeForeignCurrency:.

The implementation compiler directive — made instantly recognizable by its use of @implementation — tells the compiler that you're about to present the code that implements a class. For example,

@implementation Budget

lets the compiler know that Budget is coming down the pike. The name of the class appears after @implementation.

After getting @implementation Budget in place, you would move on to define a method:

- (void) createBudget: (double) aBudget
            withExchangeRate: (float) anExchangeRate {
  exchangeRate = anExchangeRate;
  budget = aBudget;
}

The first line of the definition of createBudget:: looks a lot like the declaration in the @interface section (one would hope), except that instead of a semicolon at the end, you find a brace. Notice that you have an argument named aBudget and an instance variable budget. If you had named that argument budget, the compiler would have needed to decide which one you meant when you tried to access the budget variable. You want to use a name like aBudget in the method declaration because it tells the reader exactly what the argument is for.

The body of the method contains these instructions:

exchangeRate = anExchangeRate;
budget = aBudget;

Adding the following lines of code after the createBudget:: method would define two more methods:

- (void) spendDollars: (double) dollars {

  budget -= dollars;
  NSLog(@"Converting %.2f US dollars into foreign currency
                          leaves $%.2f", dollars, budget);
}

- (void) chargeForeignCurrency: (double)
                                     foreignCurrency {

  exchangeTransaction = foreignCurrency*exchangeRate;
  budget -= exchangeTransaction;
  NSLog(@"Charging %.2f in foreign currency leaves $%.2f",
                                 foreignCurrency, budget);
}

Once again, the last line of code — the @end compiler directive — tells the compiler that you have finished the task at hand — in this case, the implementation file.

Allocation (alloc) starts the process of creating a new object by getting the amount of memory it needs from the operating system to hold all of the object's instance variables. For example, in the RoadTrip app, the Trip model object is allocated (as shown in Chapter 4 of Book V) as follows:

trip = [[Trip alloc] initWithName:@"Road Trip"];

NSObject, which I explain in the section, "The @interface compiler directive and first line," earlier in this chapter, is a root class that defines the basic framework for all the Objective-C objects you use and their interactions. The alloc method is one of the principal methods of NSObject for allocating memory. This code sends the alloc message to the NSObject class. The alloc method in NSObject not only allocates the memory for the object, but also initializes all the memory it allocates to 0 — all the ints are 0; all the floats become 0.0; all the pointers are nil; and the object's isa instance variable points to the object's class. (This tells an object of what class it is an instance.)

The alloc method allocates enough memory to hold all the instance variables for an object belonging to the receiving class.

You can use the new method to combine alloc and init and instantiate an object using a line of code such as

Budget  *europeBudget = [Budget new];

This instantiates (creates) a new object and sends it a message. The new method is actually a holdover from Objective-C's earlier days when a two-phase initialization was not important. Separating allocation from initialization, as you do with alloc and init, gives you individual control over each step so that each can be modified independently of the other, but you can use the new method if you don't need to exert such control.

To create a new object, you send the new message to the class you're interested in. Here's the syntax of sending a message:

[receiver message : arguments];

The receiver of a message can be either an object or a class. One of the more interesting features of Objective-C is that you can send messages to a class. If you haven't done any object-oriented programming before, sending messages to a class probably doesn't strike you as that big of a deal. But if you're coming from something like C++, it's very interesting. By sending messages to a class, you can implement behavior that is not object-specific, but applicable to an entire class.

The following line,

Budget *europeBudget = [Budget new];

sends the new message to the Budget class. The new method (inherited from NSObject) does two things, in this order:

The default init method will (more or less) initialize the instance variables to 0. Initialization, as boring as it sounds, is a very important part of working with objects. In many cases, you don't need to initialize all your instance variables. If you can live with all the instance variables initialized to 0 and nil, then there is nothing you need to do. But if your class (or your superclass) has instance variables that you need to initialize to anything other than 0 or nil, you're going to have to code some kind of initialization method. (Chapter 3 of this minibook goes into great detail about initialization and shows you how to write a proper init method for your objects.)

Objective-C, like other object-oriented programming languages, permits you to base a new class definition on a class already defined, so that the new class inherits the methods of the class it is based on. The base class is called a superclass; the new class is its subclass (I describe inheritance in detail in Chapter 2 of this book). The superclass's initialization method is always invoked before the subclass does any initialization. Your superclass is equally as respectful of its superclass and does the same thing.

When you invoke a superclass's initialization method, most of the time you get back the object you expect. Some of the framework classes such as NSString are really class clusters — a class cluster is an abstract base class (and a group of private, concrete subclasses) that hides implementation details so that their design can be modified later, without breaking your code (as long as you use the interface provided by the abstract class). When you create an object of one of these classes, its initialization method looks at the arguments you're passing and returns the object it thinks you need. If you're playing by the rules, it won't matter (as I show in Chapter 3 of this minibook).

It's possible to have more than one initializer per class. Once you have more than one initializer in a class, according to Cocoa convention, you're expected to set one up as the designated initializer. This designated initializer is usually the one that does the most initialization, and it is the one responsible for invoking the superclass's initializer. Because this initializer is the one that does the most work, again by convention, the other initializers are expected to invoke it with appropriate default values as needed. I explore this topic further in Chapter 3 of this minibook.

You need to do three things in your code in order for the compiler to create accessors for you:

In developing a vacation budget app as I describe in the previous sections, you might want to create a Destination class with methods that do the following:

To have your Destination class do all that, you'd have to add the following code to your class's Destination.h file; I explain the bold statements in more detail.

#import <Cocoa/Cocoa.h>
@class Budget;

@interface Destination : NSObject {

  NSString* country;
  double exchangeRate;
  NSMutableArray *transactions;
  Budget* theBudget;
}

- (id) initWithCountry: (NSString*) theCountry
           andBudget: (double) budgetAmount
           withExchangeRate: (double) theExchangeRate;
- (void) spendCash: (double) aTransaction;
- (void) chargeCreditCard: (double) aTransaction;
- (double) leftToSpend;

@property (nonatomic, retain) NSString* country;
@property (readwrite) double exchangeRate;
@end

Creating accessor methods is a two-step process that begins with the @property declaration, which tells the compiler that there are in fact accessor methods that it's going to have to deal with. The @property declarations for country and exchangeRate specify how the accessor methods are to behave.

The @property declaration specifies the name and type of the property and some attributes that provide the compiler with information about exactly how you want the accessor methods to be implemented.

For example, the declaration

@property (readwrite) double exchangeRate;

declares a property named exchangeRate, which is of the double type. The property attribute (readwrite) tells the compiler that this property can be both read and updated outside the object.

Now take a look at the declaration right before the exchangeRate declaration:

@property (nonatomic, retain) NSString* country;

It declares a property named country, which is a pointer to a NSString object. Enclosed in parentheses are two attributes: nonatomic and retain.

nonatomic addresses an important technical consideration for multithreaded systems, which is beyond the scope of this book. nonatomic works fine for applications like this one.

retain directs the compiler to create an accessor method that sends a retain message to any object that is assigned to this property. As I show in Chapter 3 of this minibook, properties can have some memory management implications — every object has its own reference count, or retain count. It's your responsibility to maintain that reference count by directly or indirectly increasing the retain count when you're using an object and then decreasing it when you're finished with it.

And, oh yes, nonatomic and retain apply only to pointers to objects.

But while the @property declaration tells the compiler that there are accessor methods coming — one if by land, two if by sea — the darn things still have to be created. In the good old days, you had to code these accessor methods yourself, which in a large program was very tedious.

Fortunately, Objective-C creates these accessor methods for you whenever you include a @synthesize statement for a property. To get this to work, you'd add the following code to the Destination.m file for the Destination class:

#import "Destination.h"
#import "CashTransaction.h"
#import "CreditCardTransaction.h"
#import "Budget.h"
#import "Transaction.h"

@implementation Destination

@synthesize exchangeRate, country;

The @synthesize statement — the bold line in the code — directs the compiler to create two accessor methods, one for each @property declaration.

exchangeRate
setExchangeRate:
country
setCountry:

After you've declared the properties, you can access them from other objects or from main. (main is the mother of all functions and is the place where all Objective-C programs start their execution — the instructions contained within main are always the first ones to be executed in Objective-C programs. All Objective-C programs have one.)

First, let me show you how you can access them within the class. If you want to take advantage of the retain message being sent automatically upon assignment, you have to access the instance variable directly, so you must invoke the accessor method, like this:

[self setCountry:theCountry];

You also can use the dot notation (something that refugees from other object-oriented languages might recognize).

self.country = theCountry;

[country retain];

Using an accessor method automatically sends a retain message. But you still have to release it when you're done — properties are not automatically released for you.

Normally you send an object a release message:

[country release];

But if you use an accessor method, you have a new option:

self.country = nil;

That's because when you assign a new value to a property, the accessor sends a release message to the previous object. As you can see, accessors are good citizens here.

In your dealloc method, however, you need to send the object a release message.

The file corresponding to Destination.h for the Destination class (described earlier in the "Adding properties" section) is the Destination.m file:

#import "Destination.h"
#import "CashTransaction.h"
#import "CreditCardTransaction.h"
#import "Budget.h"
#import "Transaction.h"


@implementation Destination
@synthesize exchangeRate, country;
- (id) initWithCountry: (NSString*) theCountry andBudget:
   (double) budgetAmount withExchangeRate: (double)
   theExchangeRate{
  if (self = [super init]) {
    transactions = [[NSMutableArray alloc] initWithCapacity:10];
    theBudget = [[Budget alloc]
         initWithAmount:budgetAmount forDestination:self];
    self.exchangeRate = theExchangeRate;
    [self setCountry: theCountry];

    NSLog (@"I'm off to %@", theCountry);
  }
  return self;
}

- (void) spendCash: (double)amount{

  Transaction *aTransaction = [[CashTransaction alloc]
   initWithAmount: amount forBudget: theBudget];
  [transactions addObject:aTransaction];
  [aTransaction spend];
  [aTransaction release];

}

- (void) chargeCreditCard: (double) amount{

Transaction *aTransaction = [[CreditCardTransaction alloc]
 initWithAmount: amount forBudget: theBudget];
  [transactions addObject:aTransaction];
  [aTransaction spend];
  [aTransaction release];
}

- (double) leftToSpend {

  return [theBudget returnBalance];
}

- (void) dealloc {

  [transactions release];
  [theBudget release];
  [country release];
  [super dealloc];
}

@end

The Budget init method (bolded in the preceding code) sends a message in order to get the exchangeRate:

theBudget = [[Budget alloc]
         initWithAmount:budgetAmount forDestination:self];
    self.exchangeRate = theExchangeRate;
    [self setCountry: theCountry];

An accessor method assigns the theExchangeRate argument in the initWithAmount:: method to the exchangeRate instance variable using dot notation:

self.exchangeRate = theExchangeRate;

An accessor method also assigns the theCountry argument in the initWithAmount: method to the country instance variable using an Objective-C message.

[self setCountry:theCountry];

Now that you've created these accessor methods, you can use them. First, in the Budget.m file, you use a pointer to the Destination object and include #import "Destination.h" to make the compiler happy when it sees a message to the Destination object. Here's what the Budget.m file would look like after you add the necessary code, which is in bold here, as you can see:

#import "Budget.h"

#import "Destination.h"

@implementation Budget
- (id) initWithAmount: (double) aBudget forDestination: (Destination*) aDestination {
  if (self = [super init]) {
    destination = aDestination;
    [destination retain];
    budget = aBudget;
  }
  return self;
}

- (void) spendDollars: (double) dollars {

  budget -= dollars;
}

- (void) chargeForeignCurrency: (double) foreignCurrency {
transaction = foreignCurrency*
                               [destination exchangeRate];
  budget -= transaction;
}

- (double) returnBalance {

  return budget;
}

- (void) dealloc {
  [destination release];
  [super dealloc];
}

@end

The code you added (see the preceding bolded code) uses a pointer to the Destination object as an argument:

- (id) initWithAmount: (double) aBudget forDestination: (Destination*) aDestination {
  if (self = [super init]) {
    destination = aDestination;
    [destination retain];
    budget = aBudget;
  }
  return self;
}

It also stores the pointer to the Destination object in an instance variable destination. You send it a retain message to ensure that it won't be deallocated until you are done with it.

The chargeForeignCurrency: method uses the getter method exchangeRate to get the exchange rate from the Destination object.

Next, in the Budget.h file, you add a @class statement to make the compiler happy, as well as an instance variable, destination, and an init method declaration just like in the implementation:

#import <Cocoa/Cocoa.h>
@class Destination;

@interface Budget : NSObject {
  float        exchangeRate;
  double       budget;
  double       transaction;
  Destination* destination;
}
- (id) initWithAmount: (double) aBudget
               forDestination: (Destination*) aDestination;

- (void) spendDollars: (double) dollars ;
- (void) chargeForeignCurrency: (double) euros;
- (double) returnBalance;
@end

In main, you would use the Destination object's setExchangeRate: and country accessor methods to update the exchange rate and access the country name and display it:

[europe setExchangeRate:1.30];
[england setExchangeRate:1.40];

You would also send a setExchangeRate: message to both the europe and england objects, which updates the exchange rate for each, replacing the initialized value for exchangeRate. And being a good citizen about recycling memory for other uses, you also release the string returnedCountry:

NSString *returnedCountry = [england country];
  NSLog (@"You have deleted the %@ part of your
   trip",returnedCountry);
  [returnedCountry release];
  [england release];

At the top of main, you would use the autorelease pool allocation to store objects in the autorelease pool, and at the bottom, pool drain to empty the autorelease pool as I describe in Chapter 3 of this minibook:

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

...

[pool drain];

An autorelease pool contains objects that have received an autorelease message; when drained, it sends a release message to each of those objects. By sending autorelease instead of release to an object, you can extend the lifetime of the objects — at least until the pool itself is drained.

There are times when accessor methods are the best way to do things:

Except for those and similar circumstances in your own classes, you're much better off avoiding using properties to implement an object's responsibility to accept data from (and supply data to) other objects. You should define methods that accept or supply data and not use a property that implies structural information about the data.

That being said, some features about properties also allow you to do some interesting things to mitigate the impact if you later decide to change an instance variable you've made available as a property. For example:

Objective-C, like other object-oriented programming languages, permits you to base a new class definition on a class already defined. The base class is called a superclass; the new class is its subclass. The subclass is defined only by its extension to its superclass; everything else remains the same. Each new class that you define inherits methods and instance variables of its superclass.

Inheritance allows you to do a number of things that make your programs more extensible. In a subclass, you can make three kinds of changes to the methods inherited from a superclass: add new methods and instance variables, refine or extend the behavior of a method, and change the behavior of an inherited method.

As a result, you can use a superclass's declaration (its list of methods) to define a modus operandi that all its subclasses must follow. When different classes implement similarly named methods, a program is better able to make use of polymorphism, which I describe in Chapter 2 of this minibook — adding new objects of the same type, and having your program handle them without making any changes to the code that uses them. You can also reuse code: If classes have some things in common, but also differ in key ways, the common functionality can be put in a superclass that all classes can inherit.

Delegation is a pattern used extensively in the UIKit and AppKit frameworks to customize the behavior of an object without subclassing. Instead, one object (a framework object) delegates the task of implementing one of its responsibilities to another object. You're using a behavior-rich object supplied by the framework as is and putting the code for program-specific behavior in a separate (delegate) object. When a request is made of the framework object, the method of the delegate that implements the program-specific behavior is automatically called.

You're basically using delegation to get other objects to do the work for you, as I describe in Chapter 5 of this minibook. But first, you need to discover the real truth about object-oriented programming, find out how objects behave, and especially get to know all about encapsulation, polymorphism, and how inheritance really works — all that and more is in Chapter 2.