Mac OS X Leopard - ARCAism

498
CHAPTER 26 MAC OS X DEVELOPMENT: OBJECTIVE-C
In object-oriented languages such as Java and C++, once classes are compiled, they cease to
be dynamic. You can subclass them and do what you like with your subclasses, but you can’t
change them. Your programming environment is never fully dynamic, because all any programmer
can do is create and play in a dynamic sandbox surrounding a static core.
Objective-C doesn’t have any such restrictions. Remember that Objective-C is only a very
thin layer on top of C. Except for a few compiler directives, notable by their @ prefix, very little
above plain C is actually occurring at compile time. With Objective-C, the magic happens at runtime.
That means much of what the code is doing is not locked down until right before it
happens, and therein lies tremendous power.
At the core of this is Objective-C’s unusual messaging syntax. It’s not just a readable replacement
for dot syntax; it’s actually an indirection provided by the runtime that completely
separates the act of calling a method from the actual execution of that method.
Consider the previous example:
[myObject setColorWithRed:0.4 green:0.3 blue:0.0 alpha:1.0];
In the parlance of Objective-C, we call myObject the receiver and setColorWithRed:0.4
green:0.3 blue:0.0 alpha:1.0 the message. Behind the scenes, the runtime separates the message
into a method signature and an array of arguments.
Every method signature is resolved into a selector, which is represented by the data type SEL.
The runtime dynamically pairs selectors with a method implementation, represented by the data
type IMP. These are tangible data types and can be treated as such. They can be created, examined,
changed, and passed around.
NOTE A method’s name is the method declaration, including the colons, but without the
argument names or types. So, the name of the method being called in setColorWithRed:0.4
green:0.3 blue:0.0 alpha:1.0 is setColorWithRed:green:blue:alpha:.
Categories
Even if it were possible for the designers of a library to consider every possible method programmers
might need, it would still be a bad idea. Imagine how hard it would be to use a basic class
such as NSString if it implemented every possible method. Even if you managed to page through
the thousands of available methods to find the one you need, performance would be awful.
Object-oriented programming gives you the ability to extend existing classes by subclassing
them and adding the functionality you need. For example, NSString provides a method that takes
a string and appends it to the receiver.
NSString *greeting = @"Hello";
greeting = [greeting stringByAppendingString:@", world!"];
NSLog(greeting);
Hello, world!
What if you wanted to prepend a string? That is, append it before the receiver? You can’t;
there’s no such method. However, you could subclass NSString, creating BMString:
#import
@interface BMString : NSString
- (NSString *)stringByPrependingString:(NSString *)aString;
@end