Delegation is a design pattern used extensively in the UIKit and AppKit frameworks to customize the behavior of an object without subclassing. (I talk a lot about patterns in Chapter 5 of Book I.) Instead of having to bother with subclassing, one object (a framework object) delegates the task of implementing one of its methods to another object. You can use delegation to create a class that implements the spend method of the Transaction (the delegator) class, for example, one that will behave in the same way as subclass.

To implement a delegated method, you put the code for your applicationspecific behavior in a separate (delegate) object. When a request is made of the delegator, the delegate's method that implements the applicationspecific behavior is invoked by the delegator.

The methods that a class delegates are defined in a protocol — similar to the spend: protocol you define in the Transaction class in Chapter 2 of this minibook.

The Objective-C language provides a way to formally declare a list of methods (including declared properties) as a protocol. When a framework object has been designed to use delegates to implement certain behaviors, the behaviors it requires (or gives you the option to implement) are defined in a protocol. Protocols declare methods that can be implemented by any class. They are useful for declaring methods that other delegate objects are expected to implement.

Objective-C lets you create informal protocols, which is a list of methods which a class can opt to implement (or not), and compiler-enforced formal protocols. With formal protocols, the compiler can check for types based on protocols, and objects can report whether they conform to a protocol. I start with formal protocols and cover informal ones later in this chapter.

@protocol TransactionDelegate
@required

- (void) spend: (Transaction *) aTransaction;

@optional

- (void) transaction: (Transaction *) transaction spend:
   (double) amount;

@end

@protocol ProtocolName

  method declarations
@end

@interface ClassName : ItsSuperclass < protocol list >

@interface Translator : NSObject < English, Italian >

So far, you've defined a protocol based on the Transaction class that requires Transaction class delegates to implement the spend: method. It now becomes the responsibility of the delegator, Transaction, to invoke the spend: method in its delegate. Here's how you do that in Transaction.

You added the @synthesize statement for delegate, amount, and budget to have the compiler generate the getters and setters (accessor methods) for you. When you need to have an instance variable accessible by other objects, you need to have the compiler create the getters and setter accessor methods, as I describe in Chapter 1 of this minibook).

Thus far, Destination has never created a Transaction object, and its spend: method has never been invoked. Using delegation, however, requires creating Transaction objects that invoke the delegate's spend: method in a Transaction object's spend: method.

Because this is a formal protocol, you can assume that since spend: is @required, the delegate object will have implemented it. If this were an informal protocol (which I show later in this chapter), you would need to determine whether spend is implemented. You can determine that by sending the delegate the following message, for example:

if ([delegate respondsToSelector:
                     @selector(spend:)])

respondsToSelector: is an NSObject method that tells you whether a method has been implemented. If the method has been implemented, you then send it the spend: message.

To complete the implementation of the ATM transaction you've been working on in this chapter, you need to add a method to the Destination class to process an ATM transaction just as it does cash and credit cards (as I show in Chapter 2 of this minibook). The preferred approach is to add the new method to the Destination class or add a new method to a subclass — in fact, you'd have to add a subclass if you did have the source code, as is the case with a framework — but instead of going with the preferred approach, I want to show another Objective-C feature.

One of the features of the dynamic runtime dispatch mechanism employed by Objective-C is that you can add methods to existing classes without subclassing. Objective-C calls such new methods created in this fashion categories. A category allows you to add methods to an existing class — even to one to which you don't have the source code. This is a powerful feature that allows you to extend the functionality of existing classes.

How would you use categories to add the useATM: method to your Destination class? You would start by creating a new category — ATM.

@interface Destination (ATM)

This line looks a lot like a class interface declaration — except the category name is listed within parentheses after the class name, and there is no superclass (or colon for that matter). Unlike protocols, categories do have access to all the instance variables and methods of a class. And I do mean all, even ones declared @private, but you'll need to import the interface file for the class it extends. You can also add as many categories as you want.

You can add methods to a class by declaring them in an interface file under a category name and defining them in an implementation file under the same name. What you can't do is add more instance variables.

The methods the category adds become honestly and truly part of the class type; they aren't treated as "step methods." The methods you add to Destination using the ATM category become part of the Destination class and are inherited by all the class's subclasses, just like other methods. The category methods can do anything that methods defined in the class proper can do. At runtime, there's no difference.

So, to add this new method, useATM:, to Destination, you create a category, as follows:

@interface Transaction (TransactionDelegate)

- (void) spend;

@end

@interface ATMTransactionDelegate : NSObject/*
   <TransactionDelegate> */