• Choose a category
• All
• Classic-Fiction

#import "Employee.h"

@implementation Employee

@synthesize employeeID;

- (float)bodyMassIndex

{

float normalBMI = [super bodyMassIndex];

return normalBMI * 0.9;

}

@end

Build and run the program.

To be precise, the super directive says “Run this method, but start the search for its implementation at my superclass.”

Challenge

This challenge builds on the challenge from the previous chapter.

Create a subclass of StockHolding called ForeignStockHolding. Give ForeignStockHolding an additional instance variable: conversionRate, which will be a float. (The conversion rate is what you need to multiply the local price by to get a price in US dollars. Assume the purchasePrice and currentPrice are in the local currency.) Override costInDollars and valueInDollars to do the right thing.

In main(), add a few instances of ForeignStockHolding to your array.

Figure 18.3 StockHolding and ForeignStockHolding objects

19

Object Instance Variables

Thus far, the instance variables declared in your classes have been simple C types like int or float. It’s far more common for instance variables to be pointers to other objects. An object instance variable points to another object and describes a relationship between the two objects. Usually, object instance variables fall into one of three categories:

Object-type attributes: a pointer to a simple, value-like object like an NSString or an NSNumber. For example, an employee’s last name would be stored in an NSString. Thus, an instance of Employee would have an instance variable that would be a pointer to an instance of NSString.

To-one relationships: a pointer to a single complex object. For example, an employee might have a spouse. Thus, an instance of Employee would have an instance variable that would be a pointer to an instance of Person.

To-many relationships: a pointer to an instance of a collection class, such as an NSMutableArray. (We’ll see other examples of collections in Chapter 21.) For example, an employee might have children. In this case, the instance of Employee would have an instance variable that would be a pointer to an instance of NSMutableArray. The NSMutableArray would hold a list of pointers to one or more Person objects.

(Notice that, in the above list, I refer to “an NSString.” NSString is the class, but “an NSString” is shorthand for an NSString instance. This usage is a little confusing but very common, so it’s good to get comfortable with it.)

Figure 19.1 An Employee with object instance variables

Notice that, as in other diagrams, pointers are represented by arrows. In addition, those pointers are named. So an Employee would have three new instance variables: lastName, spouse, and children. The declaration of Employee’s instance variables would look like this:

@interface Employee : Person

{

int employeeID;

NSString *lastName;

Person *spouse;

NSMutableArray *children;

}

With the exception of employeeID, these variables are all pointers. Object instance variables are always pointers. For example, the variable spouse is a pointer to another object that lives on the heap. The pointer spouse is inside the Employee object, but the Person object it points to is not. Objects don’t live inside other objects. The employee object contains its employee ID (the variable and the value itself), but it only knows where its spouse lives in memory.

There are two important side-effects to objects pointing to rather than containing other objects:

One object can take on several roles. For example, it is likely that the employee’s spouse is also listed as the emergency contact for the children:

Figure 19.2 One object, multiple roles

You end up with a lot of distinct objects using up your program’s memory. You need the objects being used to stay around, but you want the unnecessary ones to be deallocated (have their memory returned to the heap) so that their memory can be reused. Reusing memory keeps your program’s memory footprint as small as possible, which will make your entire computer