The iPhone Developer's Cookbook(1)

Object-C
In Object-C, the @ symbol is used to indicate certain keywords.

@interface and @end delineate(勾画，描述) the start and end of the class interface definition.

Object-C uses this object-based class for the most part rather than the byte-based C strings defined with char *.

Places parameters inside the method name.

Method names are also interchangeably called selectors. You see this a lot in iPhone programming, especially when you use calls to performSelector:, which lets you send messages to objects at runtime.

Uses #import to load headers rather than #include. Importing headers in Object-C automatically skips files that have already been added.

Instead of just calling functions, you ask an object to do something. This takes the form of two elements within square brackets, the object receiving the message followed by the message itself, [object message].
eg: Car *myCar = [[Car alloc] init];
The "allocate followed by init" pattern you see here represents the most common way to instantiate a new object.

Object variables point to the object itself. The pointer is 4 bytes in size. So sizeof(myCar) returns 4.

In C, you allocate memory with malloc() or a related call and free that memory with free(). In OC, you allocate memory with alloc and free it with release.[object release]

OC uses a reference-counted memory system. Each object in memory has retain count associated with it. You can see the retain count by sending retainCount to the object[object retainCount]. Every object is created with a retain count of 1.
Sending release reduces that retain count by one. When the retain count for an object reaches zero, it is released into the general memory pool.
Sending message to freed objects will crash your application.

THere is no garbage collection on the iPhone.

OC doesn't use function_name(argument) syntax. Instead, you send messages to objects using square brackets. Messages tell the object to perform a method. It is the object's responsibility to implement that method and produce a result. The first item within the brackets is the receiver of the message, the second item is a method name, and possibly some arguments to that method that together define the message you want sent. In C, you might write printCarInfo(myCar);
but in OC, you say: [myCar printCarInfo];

Dynamic Typing
OC uses dynamic typing in addition to static typing. Static typing restricts a variable declaration to a specific class at compile time. With dynamic typing, the runtime system, not the compiler, takes responsibility for asking objects what methods they can perform and what class they belong to.

With power, of course, comes responsibility.
During compilation, OC performs object message checks using static typing.

OC's dynamic typing means you can point to the same kind of object in several different ways..

While assigning a child class object to a pointer of a parent class generally works at runtime, it's far more dangerous to go the other way.

Parent-to-child assignments. Child-to-parent assignments

Because OC is a compiled language that uses dynamic typing, it does not perform many of the runtime checks that interpreted object-oriented languages do.

A child class may override a parent's method implementation, but it can't negate that the method exists. Child classes always inherit the full behavior and state package of their parents.

Since a nil(NULL) object does not point to allocated memory, you cannot access instance variables within nil.

You can send any message to nil, for example, [nil anyMethod]. The result of doing so is, in turn, nil. (Or, more accurately, 0 casted as nil.)

Class Methods
Class methods are defined using a plus(+) prefix rather than a hyphen(-). They are declared and implement int the same way as instance methods.

Why use class method at all? The answer is threefold.
First, class methods produce results without having to instantiate an actual object.
The second reason is that class methods can hide a singleton. Singletons refer to statically allocated instances. The iPhone SDK is full of these.[UIApplication sharedApplication] returns a pointer to the singleton object that is your application.[UIDevice currentDevice] retrieves an object representing the hardware platform you're working on.
Combining a class method with a singleton lets you access that static instance anywhere in your application. You don't need a pointer to the object or an instance variable that stores it.
Third, class method tie into memory management schemes.Apple's class always return those objects to you already autoreleased. Because of that, this class method pattern is fundamental part of the standard iPhone memory management system.

The root class of the OC class tree is NSObject.
UIResponder class.

Every class other than NSObject descends from other classes.

Logging Information
OC offers a fundamental logging function called NSLog. This function works like printf and uses a similar format string, but it outputs to stderr instead of stdout. NSLog uses an NSString format string rather than a C string one.

NSStrings are declared differently than C strings. They are prepended with the @(at) symbol. NSStrings are immutable, you cannot access the bytes to edit them, and the actual string data is not stored within the object.

In addition to using the standard C format specifiers, NSLog introduces an object specifier, %@, which lets you print objects. This allows you to transform
printf("Make: %s\n", [make UTF8String]);
into
NSLog(@"Make: %@", make);

NSLog does not require a hard-coded return character. It automatically appends a new line when used. What's more it adds a time stamp to every log.

CFShow() function is useful. It takes one argument, an object, and prints out a snapshot description of that object to stderr.
eg: CFShow(make);
Unlike NSLog, however, CFShow does not clutter your debugging console with time stamps. And it doesn't require format strings, which simplifies adding them to code, but they can only be used with objects. You cannot CFShow and integer or float.


Why use properties?
     It turns out that there are advantages to using properties over hand-built methods, not the least of which are dot notation and memory management.
    Properties always invoke methods. These in turn can access an object's data.So you're not, strictly speaking, breaking an object's encapsulation as properties rely on these methods to bring data outside the object. The property version of the code is more readable and ultimately easier to maintain.
    Properties simplify memory management. You can create properties that automatically retain instance variables for the lifttime of your objects and release them when you set those variables to nil. Setting a retained property ensures that memory will not be released until you say so.
    As a rule, do not send release directly to retained properties, that is, [self,colorsrelease].