You may be happily using your uPhone until one day your mechanic finds a new heater that works better and is plug-compatible with your old heater — it has the same controls. And guess what? Adding this great new heater doesn't faze your (old) uPhone one bit. It just keeps on truckin'.

The reason is that the application (including the uPhone, uPhone Interface, and Component Interface — refer to Figure 2-1) knows nothing about heaters. All the application really cares about is the heater switch (car heater control). As long as that stays the same, everything works. If the uPhone had to interact directly with the heater components without these interfaces, it wouldn't work.

To make your programs enhance-able, you want to depend on the implementation details as little as possible. You'll remember that the programming term for this I-Don't-Care-And-Please-Don't-Tell-Me approach is encapsulation. What you're doing is hiding how things are being done from what is being done.

In a program, that means hiding the internal mechanisms and data structures of a software component behind a defined interface in such a way that users of the component (other pieces of software) only need to know what the component does and don't have to make themselves dependent on the details of how the component does what it promises to do. This means the following:

This is the way modules, or objects, should work in an object-oriented program. You want the objects to limit their knowledge of other objects to what those objects can do — like turn on and off. That way, if you change something, you don't have to go digging through a zillion lines of code to figure out whether any code in your program is depending on something being done a particular way and then changing that dependent code to work with the new way it will be done. Ignorance is bliss . . . for the programmer that is.

To carry the uPhone metaphor further, imagine that your spouse or friend wants one, but she or he has a different kind of car with a different heater control. All you have to do is change the Component Interface to the heater, keeping the uPhone Interface the same — which means no changes are required to the uPhone itself.

What you're looking for is a situation in which the requestor doesn't even care who receives the message, as long as it can get what it wants. So the uPhone doesn't care whether it's sending the message to a heater in a 1959 Cadillac, or a 1958 Corvette, or even an SSC Ultimate Aero TT, as long as the heater can respond to the message.

The capability of different objects to respond, each in its own way, to identical messages is called polymorphism.

Although encapsulation allows you to ignore how things are done, polymorphism allows you to escape the specific details of differences between objects that do the same thing in different ways. In the real world, if you can drive a Chevy, you can drive a Caddy or any other car, as long as the controls are more or less the same. It isn't that a 1959 Cadillac and a 1958 Corvette are the same; if they were, what would be the point? What's important is that they are different, but you can go about using them in the same way.

In a program, different objects might perform the same methods in different ways — if the user spends cash, a cash transaction object subtracts that amount from the user's budget. If the user uses a credit card, a credit card transaction will first have to convert the amount in foreign currency that the user charged to dollars and then subtract it from the budget.

Inheritance allows you to do a number of things that make your programs more extensible and enhance-able. What kinds of things? Well, to be more specific, in a subclass you can make three kinds of changes to what you inherit from a superclass. (Think of this section as describing the mechanics of creating a subclass.)

Although a subclass can override inherited methods, it can't override inherited instance variables. If you try to declare a new one with the same name as an inherited one, the compiler complains.

Given the preceding possibilities, here are some ways you can use inheritance in your programs:

To create the Transaction superclass, you need to change the Transaction.h and Transaction.m files from earlier in Listing 2-1 and Listing 2-2 so they look like what's shown in Listing 2-4 and Listing 2-5.

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

@interface Transaction : NSObject {

Budget *budget;
  double  amount;
}

- (void) createTransaction: (double) theAmount forBudget:
    (Budget*) aBudget;
- (void) spend;
- (void) trackSpending: (double) theAmount;
@end

#import "Transaction.h"
#import "Budget.h"
@implementation Transaction
- (void) createTransaction: (double) theAmount forBudget:
   (Budget*) aBudget {
budget = aBudget;
  amount = theAmount;

}
- (void) spend {

// Fill in the method in subclasses
}

- (void) trackSpending: (double) theAmount {

  NSLog (@"You are about to spend another %.2f", theAmount);
}
@end

Go ahead and compare Listing 2-4 with Listing 2-1 (Transaction.h), and compare Listing 2-5 with Listing 2-2 (Transaction.m). You change the arguments used in createTransaction:: by deleting aType, and using aBudget instead. Each transaction sends the right message to the Budget object. You also create a skeletal spend method as a placeholder, which will be implemented in the subclasses, and delete returnAmount and returnType because you won't need them any more — you only need that information if you decide to stick with the switch statement (shown earlier in Listing 2-3).

You also add a new method, trackSpending:, which tracks your spending and uses NSLog to display a message about it (and as an example, shows you how to send messages to inherited methods):

- (void) trackSpending: (double) theAmount;

Also included in the new Transaction.h file (Listing 2-4) is the @class statement coded here as @class Budget. The compiler needs to know certain things about the classes that you're using — such as what methods you defined and so on — and the #import statement in the implementation (the new Transaction.m file in Listing 2-5) solves that problem. But when you get into objects that point at other objects, you also need to provide that information in the interface (Transaction.h file), which can cause a problem if you end up with what are known as circular dependencies (which sounds cool but is beyond the scope of this book).

To solve that problem, Objective-C introduces the @class keyword as a way to tell the compiler that the budget instance variable, whose type Budget the compiler knows nothing about (yet), is a pointer to that class. Knowing that is enough for the compiler, at least in the interface files. However, you still have to do the #import in the implementation file when you refer to methods of that class.

Next, you can take advantage of what you just did and create two subclasses of Transaction, CashTransaction (CashTransaction.h in Listing 2-6, and CashTransaction.m in Listing 2-7), and CreditCardTransaction (CreditCardTransaction.h in Listing 2-8, and CreditCardTransaction.m in Listing 2-9). They inherit all the methods and instance variables of the Transaction class, but each implements its own spend: method. You can also have both methods send a message to their superclass's trackSpending: method, which shows how to send messages to a superclass.

#import <Cocoa/Cocoa.h>
#import "Transaction.h"

@interface CashTransaction : Transaction {
}
@end

#import "CashTransaction.h"
#import "Budget.h"

@implementation CashTransaction
- (void) spend {

  [self trackSpending:amount];
  [budget spendDollars:amount];
}
@end

#import <Cocoa/Cocoa.h>
#import "Transaction.h"

@interface CreditCardTransaction : Transaction {
}
@end

#import "CreditCardTransaction.h"
#import "Budget.h"

@implementation CreditCardTransaction
- (void) spend {

[super trackSpending:amount];
  [budget chargeForeignCurrency:amount];
}
@end

To add the two new subclasses, all you have to do is declare the unique behavior in each class. You use @interface statements to specify Transaction as the superclass:

@interface CreditCardTransaction : Transaction {
@interface CashTransaction : Transaction {

Your new subclasses inherit all of the methods and instance variables of the Transaction class, which includes all the instance variables and methods it inherits from its superclass and so on up the inheritance hierarchy. (In this case, as you can see in Listing 2-4, the Transaction superclass is NSObject, so it ends there.) So you're cool when it comes to being able to behave like a good Objective-C object. And while you didn't do it here, you can also add instance variables to a subclass as well, and as many methods as you need.

You also need to import both interface files so the compiler can understand what Transaction and Budget are, so you add the #imports for the Transaction and Budget interface files because both are used by the methods in the CashTransaction and CreditCardTransaction classes.

The superclass's method trackSpending: displays that you're about to spend some money. You can have CashTransaction and CreditCardTransaction send a message to trackSpending:, in two different ways:

[self trackSpending:amount];

or

[super trackSpending:amount];

You'd use the first statement to send messages to methods that are part of your class, which includes those that you inherit. As you can see, even though trackSpending: is defined only in the Transaction superclass, your class inherited trackSpending: and the message to self works fine. Unless you have overridden the inherited trackSpending: method in your class, you should really use [super trackSpending: amount], because that makes sure that you are sending the message to the superclass method. In this case self and super are interchangeable, but as you see when you initialize objects in Chapter 3 of this minibook, that isn't always the case.

You can now use that inheritance-based Transaction class design in your program. In Objective-C programs, the instructions contained within main (the mother of all functions and the place where all Objective-C programs start their execution) are always the first ones to be executed. The main function is in the Vacation.m file (named after the Xcode project Vacation), as shown in Listing 2-10. Note that it starts off with two #import statements: The second refers to the Budget.h header file, which I show in Chapter 1 of this minibook.

#import <Foundation/Foundation.h>
#import "Budget.h"

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

int main (int argc, const char * argv[]) {

 Budget *europeBudget = [Budget new];
 [europeBudget createBudget:1000.00
                                withExchangeRate:1.2500];
 Budget *englandBudget = [Budget new];
 [englandBudget createBudget:2000.00
                                withExchangeRate:1.5000];

NSMutableArray *transactions = [[NSMutableArray alloc]
   initWithCapacity:10];
  Transaction *aTransaction ;
  for (int n = 1; n < 2; n++) {
    aTransaction = [CashTransaction new];
    [aTransaction createTransaction:n*100
                                forBudget:europeBudget];
    [transactions addObject:aTransaction];
    aTransaction = [CashTransaction new];
    [aTransaction createTransaction:n*100
                               forBudget:englandBudget];
    [transactions addObject:aTransaction];
  }

  int n =1;
  while (n < 4) {
    aTransaction = [CreditCardTransaction new];
    [aTransaction createTransaction:n*100
                                forBudget:europeBudget];
    [transactions addObject:aTransaction];

aTransaction = [CreditCardTransaction new];
    [aTransaction createTransaction:n*100
                               forBudget:englandBudget];
    [transactions addObject:aTransaction];
    n++;
  }

  for (Transaction* aTransaction in transactions) {
    [aTransaction spend];
  }

  return 0;
}

Stepping through all this code, you see that the first thing you need to do is add the necessary #import statements so the compiler knows what to do with the new classes.

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

Next, use Budget as an argument when you initialize the Transaction:

Budget *europeBudget = [Budget new];
[europeBudget createBudget:1000.00
                    withExchangeRate:1.2500];

Budget  *englandBudget = [Budget new];
[englandBudget createBudget:2000.00
                     withExchangeRate:1.5000];

The code that follows this sets up an array with NSMutableArray. As you find out in Chapter 4 of this minibook, NSMutableArray arrays are ordered collections that can contain any sort of object. The code creates the cash and credit card transactions for both Europe and England in both the for and while loops:

aTransaction = [CreditCardTransaction new];
[aTransaction createTransaction:n*100
                          forBudget:europeBudget];
[transactions addObject:aTransaction];
aTransaction = [CreditCardTransaction new];
[aTransaction createTransaction:n*100
                         forBudget:englandBudget];
[transactions addObject:aTransaction];

The code then sends the spend message to each Transaction object in the transactions array:

[aTransaction spend];

This is something you find in many applications — a set of instructions that send the same message to a list of objects. This is what polymorphism is all about — a program architecture that makes your program easier to extend. As long as your new transaction is a subclass of Transaction, it can be used immediately in your program without any changes to the rest of your program (except, of course, to create and implement the transaction itself)!

You can see how easy it is to add a new kind of transaction to the mix. All you have to do is create the new transaction type and add it to the array, and it makes itself at home with the rest of the transactions.

Revisiting Listing 2-3, you have code that iterates through an array — accesses each array object in a for loop — and uses a switch statement to decide whether to send the sendDollars: or chargeForeignCurrency: message to a budget for that kind of transaction, passing the transaction as an argument.

In the object-oriented universe, you would set up your code to have two kinds of transaction objects — cash and credit card. Both kinds respond to a spend message, and every transaction has a pointer to the budget it is associated with. You iterate through the array and send the spend message to each transaction. If it is a cash transaction in Europe, for example, it has a reference to the europeBudget object and sends it the spendDollars: message. If it is a credit card transaction in England, it sends the chargeForeignCurrency: message to englandBudget. No fuss, no bother, and no control structure. This means you have one array that holds every transaction for every country you visit — much better than managing multiple arrays for different countries and different transaction types. This enables you to change the entire switch structure in Listing 2-3 with the following:

for (Transaction*  aTransaction in transactions) {
  [aTransaction spend];
}

If you want a new transaction, all you need to do is code it up and add it to the array. And, if you wanted to visit a new country, all you'd have to do is create a budget for that country and attach it to the transactions that occurred in that country. You can see that illustrated in Figure 2-3.

Figure 2-3. Transactions and budgets.

Figure 2-3 gives you the bird's-eye view. To see how things actually work down on the ground, start with what a transaction object would look like. You'd need two instance variables:

Budget *budget;
double  amount;

You'd also need two methods:

- (void) createTransaction: (double) theAmount
                             forBudget: (Budget*) aBudget;
- (void) spend;

As you can see, besides an initialization method, you have a method named spend. You also have an instance variable, budget, which enables the Transaction object to send a message to its budget; and another instance variable, amount, which holds the amount of this transaction. Because every type of transaction has a spend method, you can enumerate through the array and send each object a spend message, and each object, depending on its type, turns around and sends the right message to its budget.

So far, both cash and credit card transactions look the same; the only difference is in the implementation of spend. The cash transaction implements spend as:

- (void) spend {
[budget spendDollars:amount];
  }

The credit card transaction looks like this:

- (void) spend {
[budget chargeForeignCurrency:amount];
  }

This ability for different objects to respond to the same message each in its own way is an example of polymorphism, and is one of the cornerstones of enhance-able and extensible programs.

The preceding sections tell you how to use one of the Objective-C extensions to C — inheritance — to implement polymorphism (or More-Of-The-Same). Polymorphism is the ability of different object types to respond to the same message, each one in its own way. Because each object can have its own version of a method, a program becomes easier to extend and enhance because you don't have to change the message to add functionality. All you have to do is create a new subclass, and it responds to the same messages in its own way.

Polymorphism allows you to isolate code in the methods of different objects rather than gathering them in a single function that has to know all the possible cases as well as in control structures such as if and switch statements. When a new case comes along, you won't have to re-code all those if and switch statements — you need only add a new class with a new method, leaving well enough alone as far as the code that you've already written, tested, and debugged is concerned.

When a message is sent, the Objective-C runtime looks at the object you're sending the message to, finds the implementation of the method matching the name, and then invokes that method.

The Cocoa framework is designed around certain programming paradigms, known as design patterns — a commonly used template that gives you a consistent way to get a particular task done.

I talk about these design patterns in Chapter 5 of Book I. The Model-View-Controller (MVC) design pattern implements the kind of object encapsulation that reduces the impact of changes to an application. This design pattern is not unique to Cocoa; a version of it has been in use since the early days of Smalltalk — the programming language that Objective-C bases its extensions to the C language on. The MVC design pattern goes a long way back, and the fact that it is still being used tells you something about its value.

MVC divides your application into three groups of objects and encourages you to limit the interaction between objects to others in its own group as much as possible. It creates, in effect, a world for the application, placing objects in one of three categories — model, view, and controller (described in the following list) — and specifies roles and responsibilities for all three kinds of objects as well as the way they're supposed to interact with each other.

Here's that list I mentioned:

What makes the separation between models, views, and controllers possible is a well-defined interface. You can create an interface between the model and a sometime-in-the-future-to-be-developed controller by using a technique called composition, which is a useful way to create interfaces. Composition is another way to hide what's really going on behind the Wizard's curtains — it keeps the objects that use the composite object ignorant of the objects the composite object uses, and actually makes the components ignorant of each other, allowing you to switch components in and out at will.

You can create a composite object — call it Destination — that interfaces to main (which is used for the time being as a surrogate for both the views and controllers). Its design is really in the @interface for Destination. To act as an interface to be used by a controller, the Destination class needs to declare methods that do the following:

In Listing 2-11, you can see the Destination class interface that accomplishes both of these tasks.