In the example of a category mentioned on page 230, you are extending the functionality of the Person object. Therefore, you write the interface like this:
Code:
@interface Person ( MeasurementsCategory )
...
@end
Once defined you need to implement the methods somewhere. One place to define these methods are in a corresponding implementation block:
Code:
@implementation Person ( MeasurementsCategory )
...
@end
You could also define the methods in the Person object. But the assumption here is its not convenient or possible to modify Person directly (maybe you don't have access to the Person object's source code). Thus, the separate block.
In the second example, you are adding a delegate callout to the Task object. At some point, you are going to give Task an object, and Task is going to message that object at specific times. We would like to use normal method-call syntax on our delegate object. But if we were to write:
Code:
id del = [self delegate];
[del executionShouldBegin:self];
The Objective-C compiler is going to complain that object 'del' might not support the executionShouldBegin: method. We use a category on NSObject to tell the Objective-C compiler that any Objective-C object (descending from NSObject) will respond to executionShouldBegin:, regardless of what it's class actually is. We write that category like so:
Code:
@interface NSObject ( TaskDelegateMethods )
- (BOOL)executionShouldBegin:(Task*)task;
...
@end
Now, it's the delegate object's job to supply the implementation for these functions. That is, if we have a class named TaskObserver, a TaskObserver object might set itself as a Task delegate. The Task delegate will try to send its delegate messages to TaskObserver. The TaskObserver class would just include these methods in its main object interface/implementation.
Code:
@interface TaskObserver : NSObject
{
}
@end
@implementation TaskObserver
- (BOOL)executionShouldBegin:(Task*)task
{
return YES;
}
....
@end
And that's exactly what we see on page 245.
Hope that helps!