Message expressions are enclosed in square brackets:

[receiver message]

The receiver can be:

The message is the name of a method plus any arguments passed to it.

The principal types used in Objective-C are defined in the header file objc/objc.h:

id can be used to type any kind of object, class, or instance. In addition, class names can be used as type names to statically type instances of a class. A statically typed instance is declared to be a pointer to an instance of its class or to an instance of any class it inherits from.

The objc.h header file also defines these useful terms:

The preprocessor understands these new notations:

Directives to the compiler begin with @. The following directives are used to declare and define classes, categories, and protocols:

The following mutually exclusive directives specify the visibility of instance variables:

The default is @protected.

In addition, there are directives for these particular purposes:

A new class is declared with the @interface directive. The interface file for its superclass must be imported:

#import "ItsSuperclass.h"

@interface ClassName : ItsSuperclass < protocol list >
{
    instance variable declarations
} 
method declarations 
@end

Everything but the compiler directives and class name is optional. If the colon and superclass name are omitted, the class is declared to be a new root class. If any protocols are listed, the header files where they’re declared must also be imported.

A file containing a class definition imports its own interface:

#import "ClassName.h"

@implementation ClassName
method definitions 
@end

You can add methods to a class by declaring them in an interface file under a category name and defining them in an implementation file under the same name. The category name indicates that the methods are additions to a class declared elsewhere, not a new class.

A category can be an alternative to a subclass. Rather than define a subclass to extend an existing class, through a category you can add methods to the class directly. For example, you could add categories to NSArray and other Cocoa classes. As in the case of a subclass, you don’t need source code for the class you’re extending.

The methods the category adds become part of the class type. For example, methods added to the NSArray class in a category will be among the methods the compiler will expect an NSArray instance to have in its repertoire. Methods added to the NSArray class in a subclass would not be included in the NSArray type. (This matters only for statically typed objects, since static typing is the only way the compiler can know an object’s class.)

Category methods can do anything that methods defined in the class proper can do. At runtime, there’s no difference. The methods the category adds to the class are inherited by all the class’s subclasses, just like other methods.

A category is declared in much the same way as a class. The interface file that declares the class must be imported:

#import "ClassName.h"

@interface ClassName ( CategoryName ) < protocol list >
method declarations 
@end

The protocol list and method declarations are optional. If any protocols are listed, the header files where they’re declared must also be imported.

Like a class definition, a file containing a category definition imports its own interface:

#import "CategoryName.h"

@implementation ClassName ( CategoryName )
method definitions
@end

Class and category interfaces declare methods that are associated with a particular class—mainly methods that the class implements. Informal and formal protocols, on the other hand, declare methods not associated with a class, but which any class, and perhaps many classes, might implement.

A protocol is simply a list of method declarations, unattached to a class definition. For example, these methods that report user actions on the mouse could be gathered into a protocol:

-(void)mouseDown:(NSEvent *)theEvent;
-(void)mouseDragged:(NSEvent *)theEvent;
-(void)mouseUp:(NSEvent *)theEvent;

Any class that wanted to respond to mouse events could adopt the protocol and implement its methods.

Protocols free method declarations from dependency on the class hierarchy, so they can be used in ways that classes and categories cannot. Protocols list methods that are (or may be) implemented somewhere, but the identity of the class that implements them is not of interest. What is of interest is whether or not a particular class conforms to the protocol—whether it has implementations of the methods the protocol declares. Thus objects can be grouped into types not just on the basis of similarities due to the fact that they inherit from the same class but also on the basis of their similarity in conforming to the same protocol. Classes in unrelated branches of the inheritance hierarchy might be typed alike because they conform to the same protocol.

Protocols can play a significant role in object-oriented design, especially when a project is divided among many implementors or incorporates objects developed in other projects. Cocoa software uses them heavily to support interprocess communication through Objective-C messages.

However, an Objective-C program doesn’t need to use protocols. Unlike class definitions and message expressions, they’re optional. Some Cocoa frameworks use them; some don’t. It all depends on the task at hand.

Formal protocols are declared using the @protocol directive:

@protocol ProtocolName
< protocol list >
method declarations
@end

The list of incorporated protocols and the method declarations are optional. The protocol must import the header files that declare any protocols it incorporates.

Within source code, protocols are referred to using the similar @protocol() directive, where the parentheses enclose the protocol name.

Protocol names listed within angle brackets <...> are used to do three different things:

Within protocol declarations, these type qualifiers support remote messaging:

The following conventions are used in method declarations:

Each method implementation is passed two hidden arguments:

Within the implementation, both self and super refer to the receiving object. super replaces self as the receiver of a message to indicate that only methods inherited by the implementation should be performed in response to the message.

Methods with no other valid return typically return void.

The names of files that contain Objective-C source code have a .m extension. Files that declare class and category interfaces or that declare protocols have the .h extension typical of header files.

Class, category, and protocol names generally begin with an uppercase letter; the names of methods and instance variables typically begin with a lowercase letter. The names of variables that hold instances usually also begin with lowercase letters.

In Objective-C, identical names that serve different purposes don’t clash. Within a class, names can assigned freely:

Likewise, protocols and categories of the same class have protected namespaces:

However, class names are in the same namespace as global variables and defined types. A program can’t have a global variable with the same name as a class.