Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. It was the main programming language supported by Apple for macOS, iOS, and their respective application programming interfaces (APIs), Cocoa and Cocoa Touch, until the introduction of Swift in 2014.

The language was originally developed in the early 1980s. It was later selected as the main language used by NeXT for its NeXTSTEP operating system, from which macOS and iOS are derived. Portable Objective-C programs that do not use Apple libraries, or those using parts that may be ported or reimplemented for other systems, can also be compiled for any system supported by GNU Compiler Collection (GCC) or Clang.

Objective-C source code ‘implementation’ program files usually have .m filename extensions, while Objective-C ‘header/interface’ files have .h extensions, the same as C header files. Objective-C++ files are denoted with a .mm file extension.

Objective-C is the primary programming language you use when writing software for OS X and iOS. It’s a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. It also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime.

At a Glance

This document introduces the Objective-C language and offers extensive examples of its use. You’ll learn how to create your own classes describing custom objects and see how to work with some of the framework classes provided by Cocoa and Cocoa Touch. Although the framework classes are separate from the language, their use is tightly wound into coding with Objective-C and many language-level features rely on behavior offered by these classes.

An App Is Built from a Network of Objects

When building apps for OS X or iOS, you’ll spend most of your time working with objects. Those objects are instances of Objective-C classes, some of which are provided for you by Cocoa or Cocoa Touch and some of which you’ll write yourself.

If you’re writing your own class, start by providing a description of the class that details the intended public interface to instances of the class. This interface includes the public properties to encapsulate relevant data, along with a list of methods. Method declarations indicate the messages that an object can receive, and include information about the parameters required whenever the method is called. You’ll also provide a class implementation, which includes the executable code for each method declared in the interface.

Relevant Chapters: Defining Classes, Working with Objects, Encapsulating Data

Categories Extend Existing Classes

Rather than creating an entirely new class to provide minor additional capabilities over an existing class, it’s possible to define a category to add custom behavior to an existing class. You can use a category to add methods to any class, including classes for which you don’t have the original implementation source code, such as framework classes like NSString.

If you do have the original source code for a class, you can use a class extension to add new properties, or modify the attributes of existing properties. Class extensions are commonly used to hide private behavior for use either within a single source code file, or within the private implementation of a custom framework.

Relevant Chapters: Customizing Existing Classes

Protocols Define Messaging Contracts

The majority of work in an Objective-C app occurs as a result of objects sending messages to each other. Often, these messages are defined by the methods declared explicitly in a class interface. Sometimes, however, it is useful to be able to define a set of related methods that aren’t tied directly to a specific class.

Objective-C uses protocols to define a group of related methods, such as the methods an object might call on its delegate, which are either optional or required. Any class can indicate that it adopts a protocol, which means that it must also provide implementations for all of the required methods in the protocol.

Relevant Chapters: Working with Protocols

Values and Collections Are Often Represented as Objective-C Objects

It’s common in Objective-C to use Cocoa or Cocoa Touch classes to represent values. The NSString class is used for strings of characters, the NSNumber class for different types of numbers such as integer or floating point, and the NSValue class for other values such as C structures. You can also use any of the primitive types defined by the C language, such as int, float or char.

Collections are usually represented as instances of one of the collection classes, such as NSArray, NSSet, or NSDictionary, which are each used to collect other Objective-C objects.

Relevant Chapters: Values and Collections

Blocks Simplify Common Tasks

Blocks are a language feature introduced to C, Objective-C and C++ to represent a unit of work; they encapsulate a block of code along with captured state, which makes them similar to closures in other programming languages. Blocks are often used to simplify common tasks such as collection enumeration, sorting and testing. They also make it easy to schedule tasks for concurrent or asynchronous execution using technologies like Grand Central Dispatch (GCD).

Relevant Chapters: Working with Blocks

Error Objects Are Used for Runtime Problems

Although Objective-C includes syntax for exception handling, Cocoa and Cocoa Touch use exceptions only for programming errors (such as out of bounds array access), which should be fixed before an app is shipped.

All other errors—including runtime problems such as running out of disk space or not being able to access a web service—are represented by instances of the NSError class. Your app should plan for errors and decide how best to handle them in order to present the best possible user experience when something goes wrong.

Relevant Chapters: Dealing with Errors

Objective-C Code Follows Established Conventions

When writing Objective-C code, you should keep in mind a number of established coding conventions. Method names, for example, start with a lowercase letter and use camel case for multiple words; for example, doSomething or doSomethingElse. It’s not just the capitalization that’s important, though; you should also make sure that your code is as readable as possible, which means that method names should be expressive, but not too verbose.

In addition, there are a few conventions that are required if you wish to take advantage of language or framework features. Property accessor methods, for example, must follow strict naming conventions in order to work with technologies like Key-Value Coding (KVC) or Key-Value Observing (KVO).

Relevant Chapters: Conventions

Prerequisites

If you are new to OS X or iOS development, you should read through Start Developing iOS Apps Today (Retired) or Start Developing Mac Apps Today before reading this document, to get a general overview of the application development process for iOS and OS X. Additionally, you should become familiar with Xcode before trying to follow the exercises at the end of most chapters in this document. Xcode is the IDE used to build apps for iOS and OS X; you’ll use it to write your code, design your app’s user interface, test your application, and debug any problems.

Although it’s preferable to have some familiarity with C or one of the C-based languages such as Java or C#, this document does include inline examples of basic C language features such as flow control statements. If you have knowledge of another higher-level programming language, such as Ruby or Python, you should be able to follow the content.

Reasonable coverage is given to general object-oriented programming principles, particularly as they apply in the context of Objective-C, but it is assumed that you have at least a minimal familiarity with basic object-oriented concepts. If you’re not familiar with these concepts, you should read the relevant chapters in Concepts in Objective-C Programming.

Defining Classes

When you write software for OS X or iOS, most of your time is spent working with objects. Objects in Objective-C are just like objects in other object-oriented programming languages: they package data with related behavior.

An app is built as a large ecosystem of interconnected objects that communicate with each other to solve specific problems, such as displaying a visual interface, responding to user input, or storing information. For OS X or iOS development, you don’t need to create objects from scratch to solve every conceivable problem; instead you have a large library of existing objects available for your use, provided by Cocoa (for OS X) and Cocoa Touch (for iOS).

Some of these objects are immediately usable, such as basic data types like strings and numbers, or user interface elements like buttons and table views. Some are designed for you to customize with your own code to behave in the way you require. The app development process involves deciding how best to customize and combine the objects provided by the underlying frameworks with your own objects to give your app its unique set of features and functionality.

In object-oriented programming terms, an object is an instance of a class. This chapter demonstrates how to define classes in Objective-C by declaring an interface, which describes the way you intend the class and its instances to be used. This interface includes the list of messages that the class can receive, so you also need to provide the class implementation, which contains the code to be executed in response to each message.

Classes Are Blueprints for Objects

A class describes the behavior and properties common to any particular type of object. For a string object (in Objective-C, this is an instance of the class NSString), the class offers various ways to examine and convert the internal characters that it represents. Similarly, the class used to describe a number object (NSNumber) offers functionality around an internal numeric value, such as converting that value to a different numeric type.

In the same way that multiple buildings constructed from the same blueprint are identical in structure, every instance of a class shares the same properties and behavior as all other instances of that class. Every NSString instance behaves in the same way, regardless of the internal string of characters it holds.

Any particular object is designed to be used in specific ways. You might know that a string object represents some string of characters, but you don’t need to know the exact internal mechanisms used to store those characters. You don’t know anything about the internal behavior used by the object itself to work directly with its characters, but you do need to know how you are expected to interact with the object, perhaps to ask it for specific characters or request a new object in which all the original characters are converted to uppercase.

In Objective-C, the class interface specifies exactly how a given type of object is intended to be used by other objects. In other words, it defines the public interface between instances of the class and the outside world.

Mutability Determines Whether a Represented Value Can Be Changed

Some classes define objects that are immutable. This means that the internal contents must be set when an object is created, and cannot subsequently be changed by other objects. In Objective-C, all basic NSString and NSNumber objects are immutable. If you need to represent a different number, you must use a new NSNumber instance.

Some immutable classes also offer a mutable version. If you specifically need to change the contents of a string at runtime, for example by appending characters as they are received over a network connection, you can use an instance of the NSMutableString class. Instances of this class behave just like NSString objects, except that they also offer functionality to change the characters that the object represents.

Although NSString and NSMutableString are different classes, they have many similarities. Rather than writing two completely separate classes from scratch that just happen to have some similar behavior, it makes sense to make use of inheritance.

Classes Inherit from Other Classes

In the natural world, taxonomy classifies animals into groups with terms like species, genus, and family. These groups are hierarchical, such that multiple species may belong to one genus, and multiple genera to one family.

Gorillas, humans, and orangutans, for example, have a number of obvious similarities. Although they each belong to different species, and even different genera, tribes, and subfamilies, they are taxonomically related since they all belong to the same family (called “Hominidae”), as shown in Figure 1-1.

Figure 1-1 Taxonomic relationships between species

In the world of object-oriented programming, objects are also categorized into hierarchical groups. Rather than using distinct terms for the different hierarchical levels such as genus or species, objects are simply organized into classes. In the same way that humans inherit certain characteristics as members of the Hominidae family, a class can be set to inherit functionality from a parent class.

When one class inherits from another, the child inherits all the behavior and properties defined by the parent. It also has the opportunity either to define its own additional behavior and properties, or override the behavior of the parent.

In the case of Objective-C string classes, the class description for NSMutableString specifies that the class inherits from NSString, as shown in Figure 1-2. All of the functionality provided by NSString is available in NSMutableString, such as querying specific characters or requesting new uppercase strings, but NSMutableString adds methods that allow you to append, insert, replace or delete substrings and individual characters.

Figure 1-2 NSMutableString class inheritance

The Root Class Provides Base Functionality

In the same way that all living organisms share some basic “life” characteristics, some functionality is common across all objects in Objective-C.

When an Objective-C object needs to work with an instance of another class, it is expected that the other class offers certain basic characteristics and behavior. For this reason, Objective-C defines a root class from which the vast majority of other classes inherit, called NSObject. When one object encounters another object, it expects to be able to interact using at least the basic behavior defined by the NSObject class description.

When you’re defining your own classes, you should at a minimum inherit from NSObject. In general, you should find a Cocoa or Cocoa Touch object that offers the closest functionality to what you need and inherit from that.

If you want to define a custom button for use in an iOS app, for example, and the provided UIButton class doesn’t offer enough customizable attributes to satisfy your needs, it makes more sense to create a new class inheriting from UIButton than from NSObject. If you simply inherited from NSObject, you’d need to duplicate all the complex visual interactions and communication defined by the UIButton class just to make your button behave in the way expected by the user. Furthermore, by inheriting from UIButton, your subclass automatically gains any future enhancements or bug fixes that might be applied to the internal UIButton behavior.

The UIButton class itself is defined to inherit from UIControl, which describes basic behavior common to all user interface controls on iOS. The UIControl class in turn inherits from UIView, giving it functionality common to objects that are displayed on screen. UIView inherits from UIResponder, allowing it to respond to user input such as taps, gestures or shakes. Finally, at the root of the tree, UIResponder inherits from NSObject, as shown in Figure 1-3.

Figure 1-3 UIButton class inheritance

This chain of inheritance means that any custom subclass of UIButton would inherit not only the functionality declared by UIButton itself, but also the functionality inherited from each superclass in turn. You’d end up with a class for an object that behaved like a button, could display itself on screen, respond to user input, and communicate with any other basic Cocoa Touch object.

It’s important to keep the inheritance chain in mind for any class you need to use, in order to work out exactly what it can do. The class reference documentation provided for Cocoa and Cocoa Touch, for example, allows easy navigation from any class to each of its superclasses. If you can’t find what you’re looking for in one class interface or reference, it may very well be defined or documented in a superclass further up the chain.

The Interface for a Class Defines Expected Interactions

One of the many benefits of object-oriented programming is the idea mentioned earlier—all you need to know in order to use a class is how to interact with its instances. More specifically, an object should be designed to hide the details of its internal implementation.

If you use a standard UIButton in an iOS app, for example, you don’t need to worry about how pixels are manipulated so that the button appears on screen. All you need to know is that you can change certain attributes, such as the button’s title and color, and trust that when you add it to your visual interface, it will be displayed correctly and behave in the way you expect.

When you’re defining your own class, you need to start by figuring out these public attributes and behaviors. What attributes do you want to be accessible publicly? Should you allow those attributes to be changed? How do other objects communicate with instances of your class?

This information goes into the interface for your class—it defines the way you intend other objects to interact with instances of your class. The public interface is described separately from the internal behavior of your class, which makes up the class implementation. In Objective-C, the interface and implementation are usually placed in separate files so that you only need to make the interface public.

Basic Syntax

The Objective-C syntax used to declare a class interface looks like this:

@interface SimpleClass : NSObject

@end

This example declares a class named SimpleClass, which inherits from NSObject.

The public properties and behavior are defined inside the @interface declaration. In this example, nothing is specified beyond the superclass, so the only functionality expected to be available on instances of SimpleClass is the functionality inherited from NSObject.

Properties Control Access to an Object’s Values

Objects often have properties intended for public access. If you define a class to represent a human being in a record-keeping app, for example, you might decide you need properties for strings representing a person’s first and last names.

Declarations for these properties should be added inside the interface, like this:

@interface Person : NSObject

@property NSString *firstName;

@property NSString *lastName;

@end

In this example, the Person class declares two public properties, both of which are instances of the NSString class.

Both these properties are for Objective-C objects, so they use an asterisk to indicate that they are C pointers. They are also statements just like any other variable declaration in C, and therefore require a semi-colon at the end.

You might decide to add a property to represent a person’s year of birth to allow you to sort people in year groups rather than just by name. You could use a property for a number object:

@property NSNumber *yearOfBirth;

but this might be considered overkill just to store a simple numeric value. One alternative would be to use one of the primitive types provided by C, which hold scalar values, such as an integer:

@property int yearOfBirth;

Property Attributes Indicate Data Accessibility and Storage Considerations

The examples shown so far all declare properties that are intended for complete public access. This means that other objects can both read and change the values of the properties.

In some cases, you might decide to declare that a property is not intended to be changed. In the real world, a person must fill out a large amount of paperwork to change their documented first or last name. If you were writing an official record-keeping app, you might choose that the public properties for a person’s name be specified as read-only, requiring that any changes be requested through an intermediary object responsible for validating the request and approving or denying it.

Objective-C property declarations can include property attributes, which are used to indicate, among other things, whether a property is intended to be read-only. In an official record-keeping app, the Person class interface might look like this:

@interface Person : NSObject

@property (readonly) NSString *firstName;

@property (readonly) NSString *lastName;

@end

Property attributes are specified inside parentheses after the @property keyword, and are described fully in Declare Public Properties for Exposed Data.

Method Declarations Indicate the Messages an Object Can Receive

The examples so far have involved a class describing a typical model object, or an object designed primarily to encapsulate data. In the case of a Person class, it’s possible that there wouldn’t need to be any functionality beyond being able to access the two declared properties. The majority of classes, however, do include behavior in addition to any declared properties.

Given that Objective-C software is built from a large network of objects, it’s important to note that those objects can interact with each other by sending messages. In Objective-C terms, one object sends a message to another object by calling a method on that object.

Objective-C methods are conceptually similar to standard functions in C and other programming languages, though the syntax is quite different. A C function declaration looks like this:

void SomeFunction();

The equivalent Objective-C method declaration looks like this:

– (void)someMethod;

In this case, the method has no parameters. The C void keyword is used inside parentheses at the beginning of the declaration to indicate that the method doesn’t return any value once it’s finished.

The minus sign (-) at the front of the method name indicates that it is an instance method, which can be called on any instance of the class. This differentiates it from class methods, which can be called on the class itself, as described in Objective-C Classes Are also Objects.

As with C function prototypes, a method declaration inside an Objective-C class interface is just like any other C statement and requires a terminating semi-colon.

Methods Can Take Parameters

If you need to declare a method to take one or more parameters, the syntax is very different to a typical C function.

For a C function, the parameters are specified inside parentheses, like this:

void SomeFunction(SomeType value);

An Objective-C method declaration includes the parameters as part of its name, using colons, like this:

– (void)someMethodWithValue:(SomeType)value;

As with the return type, the parameter type is specified in parentheses, just like a standard C type-cast.

If you need to supply multiple parameters, the syntax is again quite different from C. Multiple parameters to a C function are specified inside the parentheses, separated by commas; in Objective-C, the declaration for a method taking two parameters looks like this:

– (void)someMethodWithFirstValue:(SomeType)value1 secondValue:(AnotherType)value2;

In this example, value1 and value2 are the names used in the implementation to access the values supplied when the method is called, as if they were variables.

Some programming languages allow function definitions with so-called named arguments; it’s important to note that this is not the case in Objective-C. The order of the parameters in a method call must match the method declaration, and in fact the secondValue: portion of the method declaration is part of the name of the method:

someMethodWithFirstValue:secondValue:

This is one of the features that helps make Objective-C such a readable language, because the values passed by a method call are specified inline, next to the relevant portion of the method name, as described in You Can Pass Objects for Method Parameters.

Note: The value1 and value2 value names used above aren’t strictly part of the method declaration, which means it’s not necessary to use exactly the same value names in the declaration as you do in the implementation. The only requirement is that the signature matches, which means you must keep the name of the method as well as the parameter and return types exactly the same.

As an example, this method has the same signature as the one shown above:

– (void)someMethodWithFirstValue:(SomeType)info1 secondValue:(AnotherType)info2;

These methods have different signatures to the one above:

– (void)someMethodWithFirstValue:(SomeType)info1 anotherValue:(AnotherType)info2;

– (void)someMethodWithFirstValue:(SomeType)info1 secondValue:(YetAnotherType)info2;

Class Names Must Be Unique

It’s important to note that the name of each class must be unique within an app, even across included libraries or frameworks. If you attempt to create a new class with the same name as an existing class in a project, you’ll receive a compiler error.

For this reason, it’s advisable to prefix the names of any classes you define, using three or more letters. These letters might relate to the app you’re currently writing, or to the name of a framework of reusable code, or perhaps just your initials.

All examples given in the rest of this document use class name prefixes, like this:

@interface XYZPerson : NSObject

@property (readonly) NSString *firstName;

@property (readonly) NSString *lastName;

@end

Historical Note: If you’re wondering why so many of the classes you encounter have an NS prefix, it’s because of the past history of Cocoa and Cocoa Touch. Cocoa began life as the collected frameworks used to build apps for the NeXTStep operating system. When Apple purchased NeXT back in 1996, much of NeXTStep was incorporated into OS X, including the existing class names. Cocoa Touch was introduced as the iOS equivalent of Cocoa; some classes are available in both Cocoa and Cocoa Touch, though there are also a large number of classes unique to each platform.

Two-letter prefixes like NS and UI (for User Interface elements on iOS) are reserved for use by Apple.

Method and property names, by contrast, need only be unique within the class in which they are defined. Although every C function in an app must have a unique name, it’s perfectly acceptable (and often desirable) for multiple Objective-C classes to define methods with the same name. You can’t define a method more than once within the same class declaration, however, though if you wish to override a method inherited from a parent class, you must use the exact name used in the original declaration.

As with methods, an object’s properties and instance variables (described in Most Properties Are Backed by Instance Variables) need to be unique only within the class in which they are defined. If you make use of global variables, however, these must be named uniquely within an app or project.

Further naming conventions and suggestions are given in Conventions.

The Implementation of a Class Provides Its Internal Behavior

Once you’ve defined the interface for a class, including the properties and methods intended for public access, you need to write the code to implement the class behavior.

As stated earlier, the interface for a class is usually placed inside a dedicated file, often referred to as a header file, which generally has the filename extension .h. You write the implementation for an Objective-C class inside a source code file with the extension .m.

Whenever the interface is defined in a header file, you’ll need to tell the compiler to read it before trying to compile the implementation in the source code file. Objective-C provides a preprocessor directive, #import, for this purpose. It’s similar to the C #include directive, but makes sure that a file is only included once during compilation.

Note that preprocessor directives are different from traditional C statements and do not use a terminating semi-colon.

Basic Syntax

The basic syntax to provide the implementation for a class looks like this:

#import “XYZPerson.h”

@implementation XYZPerson

@end

If you declare any methods in the class interface, you’ll need to implement them inside this file.

Implementing Methods

For a simple class interface with one method, like this:

@interface XYZPerson : NSObject

– (void)sayHello;

@end

the implementation might look like this:

#import “XYZPerson.h”

@implementation XYZPerson

– (void)sayHello {

NSLog(@”Hello, World!”);

}

@end

This example uses the NSLog() function to log a message to the console. It’s similar to the standard C library printf() function, and takes a variable number of parameters, the first of which must be an Objective-C string.

Method implementations are similar to C function definitions in that they use braces to contain the relevant code. Furthermore, the name of the method must be identical to its prototype, and the parameter and return types must match exactly.

Objective-C inherits case sensitivity from C, so this method:

– (void)sayhello {

}

would be treated by the compiler as completely different to the sayHello method shown earlier.

In general, method names should begin with a lowercase letter. The Objective-C convention is to use more descriptive names for methods than you might see used for typical C functions. If a method name involves multiple words, use camel case (capitalizing the first letter of each new word) to make them easy to read.

Note also that whitespace is flexible in Objective-C. It’s customary to indent each line inside any block of code using either tabs or spaces, and you’ll often see the opening left brace on a separate line, like this:

– (void)sayHello

{

NSLog(@”Hello, World!”);

}

Xcode, Apple’s integrated development environment (IDE) for creating OS X and iOS software, will automatically indent your code based on a set of customizable user preferences. See Changing the Indent and Tab Width in Xcode Workspace Guide for more information.

You’ll see many more examples of method implementations in the next chapter, Working with Objects.

Objective-C Classes Are also Objects

In Objective-C, a class is itself an object with an opaque type called Class. Classes can’t have properties defined using the declaration syntax shown earlier for instances, but they can receive messages.

The typical use for a class method is as a factory method, which is an alternative to the object allocation and initialization procedure described in Objects Are Created Dynamically. The NSString class, for example, has a variety of factory methods available to create either an empty string object, or a string object initialized with specific characters, including:

+ (id)string;

+ (id)stringWithString:(NSString *)aString;

+ (id)stringWithFormat:(NSString *)format, …;

+ (id)stringWithContentsOfFile:(NSString *)path encoding:(NSStringEncoding)enc error:(NSError **)error;

+ (id)stringWithCString:(const char *)cString encoding:(NSStringEncoding)enc;

As shown in these examples, class methods are denoted by the use of a + sign, which differentiates them from instance methods using a - sign.

Class method prototypes may be included in a class interface, just like instance method prototypes. Class methods are implemented in the same way as instance methods, inside the @implementation block for the class.

Exercises

Note: In order to follow the exercises given at the end of each chapter, you may wish to create an Xcode project. This will allow you to make sure that your code compiles without errors.

Use Xcode’s New Project template window to create a Command Line Tool from the available OS X Application project templates. When prompted, specify the project’s Type as Foundation.

Use Xcode’s New File template window to create the interface and implementation files for an Objective-C class called XYZPerson, which inherits from NSObject.
Add properties for a person’s first name, last name and date of birth (dates are represented by the NSDate class) to the XYZPerson class interface.
Declare the sayHello method and implement it as shown earlier in the chapter.
Add a declaration for a class factory method, called “person”. Don’t worry about implementing this method until you’ve read the next chapter.Note: If you’re compiling the code, you’ll get a warning about an “Incomplete implementation” due to this missing implementation.

Working with Objects

The majority of work in an Objective-C application happens as a result of messages being sent back and forth across an ecosystem of objects. Some of these objects are instances of classes provided by Cocoa or Cocoa Touch, some are instances of your own classes.

The previous chapter described the syntax to define the interface and implementation for a class, including the syntax to implement methods containing the code to be executed in response to a message. This chapter explains how to send such a message to an object, and includes coverage of some of Objective-C’s dynamic features, including dynamic typing and the ability to determine which method should be invoked at runtime.

Before an object can be used, it must be created properly using a combination of memory allocation for its properties and any necessary initialization of its internal values. This chapter describes how to nest the method calls to allocate and initialize an object in order to ensure that it is configured correctly.

Objects Send and Receive Messages

Although there are several different ways to send messages between objects in Objective-C, by far the most common is the basic syntax that uses square brackets, like this:

[someObject doSomething];

The reference on the left, someObject in this case, is the receiver of the message. The message on the right, doSomething, is the name of the method to call on that receiver. In other words, when the above line of code is executed, someObject will be sent the doSomething message.

The previous chapter described how to create the interface for a class, like this:

@interface XYZPerson : NSObject

– (void)sayHello;

@end

and how to create the implementation of that class, like this:

@implementation XYZPerson

– (void)sayHello {

NSLog(@”Hello, world!”);

}

@end

Note: This example uses an Objective-C string literal, @"Hello, world!". Strings are one of several class types in Objective-C that allow a shorthand literal syntax for their creation. Specifying @"Hello, world!" is conceptually equivalent to saying “An Objective-C string object that represents the string Hello, world!.”

Literals and object creation are explained further in Objects Are Created Dynamically, later in this chapter.

Assuming you’ve got hold of an XYZPerson object, you could send it the sayHello message like this:

[somePerson sayHello];

Sending an Objective-C message is conceptually very much like calling a C function. Figure 2-1 shows the effective program flow for the sayHello message.

Figure 2-1 Basic messaging program flow

In order to specify the receiver of a message, it’s important to understand how pointers are used to refer to objects in Objective-C.

Use Pointers to Keep Track of Objects

C and Objective-C use variables to keep track of values, just like most other programming languages.

There are a number of basic scalar variable types defined in standard C, including integers, floating-point numbers and characters, which are declared and assigned values like this:

int someInteger = 42;

float someFloatingPointNumber = 3.14f;

Local variables, which are variables declared within a method or function, like this:

– (void)myMethod {

int someInteger = 42;

}

are limited in scope to the method in which they are defined.

In this example, someInteger is declared as a local variable inside myMethod; once execution reaches the closing brace of the method, someInteger will no longer be accessible. When a local scalar variable (like an int or a float) goes away, the value disappears too.

Objective-C objects, by contrast, are allocated slightly differently. Objects normally have a longer life than the simple scope of a method call. In particular, an object often needs to stay alive longer than the original variable that was created to keep track of it, so an object’s memory is allocated and deallocated dynamically.

Note: If you’re used to using terms like the stack and the heap, a local variable is allocated on the stack, while objects are allocated on the heap.

This requires you to use C pointers (which hold memory addresses) to keep track of their location in memory, like this:

– (void)myMethod {

NSString *myString = // get a string from somewhere…

[…]

}

Although the scope of the pointer variable myString (the asterisk indicates it’s a pointer) is limited to the scope of myMethod, the actual string object that it points to in memory may have a longer life outside that scope. It might already exist, or you might need to pass the object around in additional method calls, for example.

You Can Pass Objects for Method Parameters

If you need to pass along an object when sending a message, you supply an object pointer for one of the method parameters. The previous chapter described the syntax to declare a method with a single parameter:

– (void)someMethodWithValue:(SomeType)value;

The syntax to declare a method that takes a string object, therefore, looks like this:

– (void)saySomething:(NSString *)greeting;

You might implement the saySomething: method like this:

– (void)saySomething:(NSString *)greeting {

NSLog(@”%@”, greeting);

}

The greeting pointer behaves like a local variable and is limited in scope just to the saySomething: method, even though the actual string object that it points to existed prior to the method being called, and will continue to exist after the method completes.

Note: NSLog() uses format specifiers to indicate substitution tokens, just like the C standard library printf() function. The string logged to the console is the result of modifying the format string (the first argument) by inserting the provided values (the remaining arguments).

There is one additional substitution token available in Objective-C, %@, used to denote an object. At runtime, this specifier will be substituted with the result of calling either the descriptionWithLocale: method (if it exists) or the description method on the provided object. The description method is implemented by NSObject to return the class and memory address of the object, but many Cocoa and Cocoa Touch classes override it to provide more useful information. In the case of NSString, the description method simply returns the string of characters that it represents.

For more information about the available format specifiers for use with NSLog() and the NSString class, see String Format Specifiers.

Methods Can Return Values

As well as passing values through method parameters, it’s possible for a method to return a value. Each method shown in this chapter so far has a return type of void. The C void keyword means a method doesn’t return anything.

Specifying a return type of int means that the method returns a scalar integer value:

– (int)magicNumber;

The implementation of the method uses a C return statement to indicate the value that should be passed back after the method has finished executing, like this:

– (int)magicNumber {

return 42;

}

It’s perfectly acceptable to ignore the fact that a method returns a value. In this case the magicNumber method doesn’t do anything useful other than return a value, but there’s nothing wrong with calling the method like this:

[someObject magicNumber];

If you do need to keep track of the returned value, you can declare a variable and assign it to the result of the method call, like this:

int interestingNumber = [someObject magicNumber];

You can return objects from methods in just the same way. The NSString class, for example, offers an uppercaseString method:

– (NSString *)uppercaseString;

It’s used in the same way as a method returning a scalar value, although you need to use a pointer to keep track of the result:

NSString *testString = @”Hello, world!”;

NSString *revisedString = [testString uppercaseString];

When this method call returns, revisedString will point to an NSString object representing the characters HELLO WORLD!.

Remember that when implementing a method to return an object, like this:

– (NSString *)magicString {

NSString *stringToReturn = // create an interesting string…

return stringToReturn;

}

the string object continues to exist when it is passed as a return value even though the stringToReturn pointer goes out of scope.

There are some memory management considerations in this situation: a returned object (created on the heap) needs to exist long enough for it to be used by the original caller of the method, but not in perpetuity because that would create a memory leak. For the most part, the Automatic Reference Counting (ARC) feature of the Objective-C compiler takes care of these considerations for you.

Objects Can Send Messages to Themselves

Whenever you’re writing a method implementation, you have access to an important hidden value, self. Conceptually, self is a way to refer to “the object that’s received this message.” It’s a pointer, just like the greeting value above, and can be used to call a method on the current receiving object.

You might decide to refactor the XYZPerson implementation by modifying the sayHello method to use the saySomething: method shown above, thereby moving the NSLog() call to a separate method. This would mean you could add further methods, like sayGoodbye, that would each call through to the saySomething: method to handle the actual greeting process. If you later wanted to display each greeting in a text field in the user interface, you’d only need to modify the saySomething: method rather than having to go through and adjust each greeting method individually.

The new implementation using self to call a message on the current object would look like this:

@implementation XYZPerson

– (void)sayHello {

[self saySomething:@”Hello, world!”];

}

– (void)saySomething:(NSString *)greeting {

NSLog(@”%@”, greeting);

}

@end

If you sent an XYZPerson object the sayHello message for this updated implementation, the effective program flow would be as shown in Figure 2-2.

Figure 2-2 Program flow when messaging self

Objects Can Call Methods Implemented by Their Superclasses

There’s another important keyword available to you in Objective-C, called super. Sending a message to super is a way to call through to a method implementation defined by a superclass further up the inheritance chain. The most common use of super is when overriding a method.

Let’s say you want to create a new type of person class, a “shouting person” class, where every greeting is displayed using capital letters. You could duplicate the entire XYZPerson class and modify each string in each method to be uppercase, but the simplest way would be to create a new class that inherits from XYZPerson, and just override the saySomething: method so that it displays the greeting in uppercase, like this:

@interface XYZShoutingPerson : XYZPerson

@end

@implementation XYZShoutingPerson

– (void)saySomething:(NSString *)greeting {

NSString *uppercaseGreeting = [greeting uppercaseString];

NSLog(@”%@”, uppercaseGreeting);

}

@end

This example declares an extra string pointer, uppercaseGreeting and assigns it the value returned from sending the original greeting object the uppercaseString message. As you saw earlier, this will be a new string object built by converting each character in the original string to uppercase.

Because sayHello is implemented by XYZPerson, and XYZShoutingPerson is set to inherit from XYZPerson, you can call sayHello on an XYZShoutingPerson object as well. When you call sayHello on an XYZShoutingPerson, the call to [self saySomething:...] will use the overridden implementation and display the greeting as uppercase, resulting in the effective program flow shown in Figure 2-3.

Figure 2-3 Program flow for an overridden method

The new implementation isn’t ideal, however, because if you did decide later to modify the XYZPerson implementation of saySomething: to display the greeting in a user interface element rather than through NSLog(), you’d need to modify the XYZShoutingPerson implementation as well.

A better idea would be to change the XYZShoutingPerson version of saySomething: to call through to the superclass (XYZPerson) implementation to handle the actual greeting:

@implementation XYZShoutingPerson

– (void)saySomething:(NSString *)greeting {

NSString *uppercaseGreeting = [greeting uppercaseString];

[super saySomething:uppercaseGreeting];

}

@end

The effective program flow that now results from sending an XYZShoutingPerson object the sayHello message is shown in Figure 2-4.

Figure 2-4 Program flow when messaging super

Objects Are Created Dynamically

As described earlier in this chapter, memory is allocated dynamically for an Objective-C object. The first step in creating an object is to make sure enough memory is allocated not only for the properties defined by an object’s class, but also the properties defined on each of the superclasses in its inheritance chain.

The NSObject root class provides a class method, alloc, which handles this process for you:

+ (id)alloc;

Notice that the return type of this method is id. This is a special keyword used in Objective-C to mean “some kind of object.” It is a pointer to an object, like (NSObject *), but is special in that it doesn’t use an asterisk. It’s described in more detail later in this chapter, in Objective-C Is a Dynamic Language.

The alloc method has one other important task, which is to clear out the memory allocated for the object’s properties by setting them to zero. This avoids the usual problem of memory containing garbage from whatever was stored before, but is not enough to initialize an object completely.

You need to combine a call to alloc with a call to init, another NSObject method:

– (id)init;

The init method is used by a class to make sure its properties have suitable initial values at creation, and is covered in more detail in the next chapter.

Note that init also returns an id.

If one method returns an object pointer, it’s possible to nest the call to that method as the receiver in a call to another method, thereby combining multiple message calls in one statement. The correct way to allocate and initialize an object is to nest the alloc call inside the call to init, like this:

NSObject *newObject = [[NSObject alloc] init];

This example sets the newObject variable to point to a newly created NSObject instance.

The innermost call is carried out first, so the NSObject class is sent the alloc method, which returns a newly allocated NSObject instance. This returned object is then used as the receiver of the init message, which itself returns the object back to be assigned to the newObject pointer, as shown in Figure 2-5.

Figure 2-5 Nesting the alloc and init message

Note: It’s possible for init to return a different object than was created by alloc, so it’s best practice to nest the calls as shown.

Never initialize an object without reassigning any pointer to that object. As an example, don’t do this:

NSObject *someObject = [NSObject alloc];

[someObject init];

If the call to init returns some other object, you’ll be left with a pointer to the object that was originally allocated but never initialized.

Initializer Methods Can Take Arguments

Some objects need to be initialized with required values. An NSNumber object, for example, must be created with the numeric value it needs to represent.

The NSNumber class defines several initializers, including:

– (id)initWithBool:(BOOL)value;

– (id)initWithFloat:(float)value;

– (id)initWithInt:(int)value;

– (id)initWithLong:(long)value;

Initialization methods with arguments are called in just the same way as plain init methods—an NSNumber object is allocated and initialized like this:

NSNumber *magicNumber = [[NSNumber alloc] initWithInt:42];

Class Factory Methods Are an Alternative to Allocation and Initialization

As mentioned in the previous chapter, a class can also define factory methods. Factory methods offer an alternative to the traditional alloc] init] process, without the need to nest two methods.

The NSNumber class defines several class factory methods to match its initializers, including:

+ (NSNumber *)numberWithBool:(BOOL)value;

+ (NSNumber *)numberWithFloat:(float)value;

+ (NSNumber *)numberWithInt:(int)value;

+ (NSNumber *)numberWithLong:(long)value;

A factory method is used like this:

NSNumber *magicNumber = [NSNumber numberWithInt:42];

This is effectively the same as the previous example using alloc] initWithInt:]. Class factory methods usually just call straight through to alloc and the relevant init method, and are provided for convenience.

Use new to Create an Object If No Arguments Are Needed for Initialization

It’s also possible to create an instance of a class using the new class method. This method is provided by NSObject and doesn’t need to be overridden in your own subclasses.

It’s effectively the same as calling alloc and init with no arguments:

XYZObject *object = [XYZObject new];

// is effectively the same as:

XYZObject *object = [[XYZObject alloc] init];

Literals Offer a Concise Object-Creation Syntax

Some classes allow you to use a more concise, literal syntax to create instances.

You can create an NSString instance, for example, using a special literal notation, like this:

NSString *someString = @”Hello, World!”;

This is effectively the same as allocating and initializing an NSString or using one of its class factory methods:

NSString *someString = [NSString stringWithCString:”Hello, World!”

encoding:NSUTF8StringEncoding];

The NSNumber class also allows a variety of literals:

NSNumber *myBOOL = @YES;

NSNumber *myFloat = @3.14f;

NSNumber *myInt = @42;

NSNumber *myLong = @42L;

Again, each of these examples is effectively the same as using the relevant initializer or a class factory method.

You can also create an NSNumber using a boxed expression, like this:

NSNumber *myInt = @(84 / 2);

In this case, the expression is evaluated, and an NSNumber instance created with the result.

Objective-C also supports literals to create immutable NSArray and NSDictionary objects; these are discussed further in Values and Collections.

Objective-C Is a Dynamic Language

As mentioned earlier, you need to use a pointer to keep track of an object in memory. Because of Objective-C’s dynamic nature, it doesn’t matter what specific class type you use for that pointer—the correct method will always be called on the relevant object when you send it a message.

The id type defines a generic object pointer. It’s possible to use id when declaring a variable, but you lose compile-time information about the object.

Consider the following code:

id someObject = @”Hello, World!”;

[someObject removeAllObjects];

In this case, someObject will point to an NSString instance, but the compiler knows nothing about that instance beyond the fact that it’s some kind of object. The removeAllObjects message is defined by some Cocoa or Cocoa Touch objects (such as NSMutableArray) so the compiler doesn’t complain, even though this code would generate an exception at runtime because an NSString object can’t respond to removeAllObjects.

Rewriting the code to use a static type:

NSString *someObject = @”Hello, World!”;

[someObject removeAllObjects];

means that the compiler will now generate an error because removeAllObjects is not declared in any public NSString interface that it knows about.

Because the class of an object is determined at runtime, it makes no difference what type you assign a variable when creating or working with an instance. To use the XYZPerson and XYZShoutingPerson classes described earlier in this chapter, you might use the following code:

XYZPerson *firstPerson = [[XYZPerson alloc] init];

XYZPerson *secondPerson = [[XYZShoutingPerson alloc] init];

[firstPerson sayHello];

[secondPerson sayHello];

Although both firstPerson and secondPerson are statically typed as XYZPerson objects, secondPerson will point, at runtime, to an XYZShoutingPerson object. When the sayHello method is called on each object, the correct implementations will be used; for secondPerson, this means the XYZShoutingPerson version.

Determining Equality of Objects

If you need to determine whether one object is the same as another object, it’s important to remember that you’re working with pointers.

The standard C equality operator == is used to test equality between the values of two variables, like this:

if (someInteger == 42) {

// someInteger has the value 42

}

When dealing with objects, the == operator is used to test whether two separate pointers are pointing to the same object:

if (firstPerson == secondPerson) {

// firstPerson is the same object as secondPerson

}

If you need to test whether two objects represent the same data, you need to call a method like isEqual:, available from NSObject:

if ([firstPerson isEqual:secondPerson]) {

// firstPerson is identical to secondPerson

}

If you need to compare whether one object represents a greater or lesser value than another object, you can’t use the standard C comparison operators > and <. Instead, the basic Foundation types, like NSNumber, NSString and NSDate, provide a compare: method:

if ([someDate compare:anotherDate] == NSOrderedAscending) {

// someDate is earlier than anotherDate

}

Working with nil

It’s always a good idea to initialize scalar variables at the time you declare them, otherwise their initial values will contain garbage from the previous stack contents:

BOOL success = NO;

int magicNumber = 42;

This isn’t necessary for object pointers, because the compiler will automatically set the variable to nil if you don’t specify any other initial value:

XYZPerson *somePerson;

// somePerson is automatically set to nil

A nil value is the safest way to initialize an object pointer if you don’t have another value to use, because it’s perfectly acceptable in Objective-C to send a message to nil. If you do send a message to nil, obviously nothing happens.

Note: If you expect a return value from a message sent to nil, the return value will be nil for object return types, 0 for numeric types, and NO for BOOL types. Returned structures have all members initialized to zero.

If you need to check to make sure an object is not nil (that a variable points to an object in memory), you can either use the standard C inequality operator:

if (somePerson != nil) {

// somePerson points to an object

}

or simply supply the variable:

if (somePerson) {

// somePerson points to an object

}

If the somePerson variable is nil, its logical value is 0 (false). If it has an address, it’s not zero, so evaluates as true.

Similarly, if you need to check for a nil variable, you can either use the equality operator:

if (somePerson == nil) {

// somePerson does not point to an object

}

or just use the C logical negation operator:

if (!somePerson) {

// somePerson does not point to an object

}

Exercises

Open the main.m file in your project from the exercises at the end of the last chapter and find the main() function. As with any executable written in C, this function represents the starting point for your application.Create a new XYZPerson instance using alloc and init, and then call the sayHello method.Note: If the compiler doesn’t prompt you automatically, you will need to import the header file (containing the XYZPerson interface) at the top of main.m.
Implement the saySomething: method shown earlier in this chapter, and rewrite the sayHello method to use it. Add a variety of other greetings and call each of them on the instance you created above.
Create new class files for the XYZShoutingPerson class, set to inherit from XYZPerson.Override the saySomething: method to display the uppercase greeting, and test the behavior on an XYZShoutingPerson instance.
Implement the XYZPerson class person factory method you declared in the previous chapter, to return a correctly allocated and initialized instance of the XYZPerson class, then use the method in main() instead of your nested alloc and init.Tip: Rather than using [[XYZPerson alloc] init] in the class factory method, instead try using [[self alloc] init].Using self in a class factory method means that you’re referring to the class itself.This means that you don’t have to override the person method in the XYZShoutingPerson implementation to create the correct instance. Test this by checking that: XYZShoutingPerson *shoutingPerson = [XYZShoutingPerson person];creates the correct type of object.
Create a new local XYZPerson pointer, but don’t include any value assignment.Use a branch (if statement) to check whether the variable is automatically assigned as nil.

Encapsulating Data

In addition to the messaging behavior covered in the previous chapter, an object also encapsulates data through its properties.

This chapter describes the Objective-C syntax used to declare properties for an object and explains how those properties are implemented by default through synthesis of accessor methods and instance variables. If a property is backed by an instance variable, that variable must be set correctly in any initialization methods.

If an object needs to maintain a link to another object through a property, it’s important to consider the nature of the relationship between the two objects. Although memory management for Objective-C objects is mostly handled for you through Automatic Reference Counting (ARC), it’s important to know how to avoid problems like strong reference cycles, which lead to memory leaks. This chapter explains the lifecycle of an object, and describes how to think in terms of managing your graph of objects through relationships.

Properties Encapsulate an Object’s Values

Most objects need to keep track of information in order to perform their tasks. Some objects are designed to model one or more values, such as a Cocoa NSNumber class to hold a numeric value or a custom XYZPerson class to model a person with a first and last name. Some objects are more general in scope, perhaps handling the interaction between a user interface and the information it displays, but even these objects need to keep track of user interface elements or the related model objects.

Declare Public Properties for Exposed Data

Objective-C properties offer a way to define the information that a class is intended to encapsulate. As you saw in Properties Control Access to an Object’s Values, property declarations are included in the interface for a class, like this:

@interface XYZPerson : NSObject

@property NSString *firstName;

@property NSString *lastName;

@end

In this example, the XYZPerson class declares string properties to hold a person’s first and last name.

Given that one of the primary principles in object-oriented programming is that an object should hide its internal workings behind its public interface, it’s important to access an object’s properties using behavior exposed by the object rather than trying to gain access to the internal values directly.

Use Accessor Methods to Get or Set Property Values

You access or set an object’s properties via accessor methods:

NSString *firstName = [somePerson firstName];

[somePerson setFirstName:@”Johnny”];

By default, these accessor methods are synthesized automatically for you by the compiler, so you don’t need to do anything other than declare the property using @property in the class interface.

The synthesized methods follow specific naming conventions:

The method used to access the value (the getter method) has the same name as the property.The getter method for a property called firstName will also be called firstName.
The method used to set the value (the setter method) starts with the word “set” and then uses the capitalized property name.The setter method for a property called firstName will be called setFirstName:.

If you don’t want to allow a property to be changed via a setter method, you can add an attribute to a property declaration to specify that it should be readonly:

@property (readonly) NSString *fullName;

As well as showing other objects how they are supposed to interact with the property, attributes also tell the compiler how to synthesize the relevant accessor methods.

In this case, the compiler will synthesize a fullName getter method, but not a setFullName: method.

Note: The opposite of readonly is readwrite. There’s no need to specify the readwrite attribute explicitly, because it is the default.

If you want to use a different name for an accessor method, it’s possible to specify a custom name by adding attributes to the property. In the case of Boolean properties (properties that have a YES or NO value), it’s customary for the getter method to start with the word “is.” The getter method for a property called finished, for example, should be called isFinished.

Again, it’s possible to add an attribute on the property:

@property (getter=isFinished) BOOL finished;

If you need to specify multiple attributes, simply include them as a comma-separated list, like this:

@property (readonly, getter=isFinished) BOOL finished;

In this case, the compiler will synthesize only an isFinished method, but not a setFinished: method.

Note: In general, property accessor methods should be Key-Value Coding (KVC) compliant, which means that they follow explicit naming conventions.

See Key-Value Coding Programming Guide for more information.

Dot Syntax Is a Concise Alternative to Accessor Method Calls

As well as making explicit accessor method calls, Objective-C offers an alternative dot syntax to access an object’s properties.

Dot syntax allows you to access properties like this:

NSString *firstName = somePerson.firstName;

somePerson.firstName = @”Johnny”;

Dot syntax is purely a convenient wrapper around accessor method calls. When you use dot syntax, the property is still accessed or changed using the getter and setter methods mentioned above:

Getting a value using somePerson.firstName is the same as using [somePerson firstName]
Setting a value using somePerson.firstName = @"Johnny" is the same as using [somePerson setFirstName:@"Johnny"]

This means that property access via dot syntax is also controlled by the property attributes. If a property is marked readonly, you’ll get a compiler error if you try to set it using dot syntax.

Most Properties Are Backed by Instance Variables

By default, a readwrite property will be backed by an instance variable, which will again be synthesized automatically by the compiler.

An instance variable is a variable that exists and holds its value for the life of the object. The memory used for instance variables is allocated when the object is first created (through alloc), and freed when the object is deallocated.

Unless you specify otherwise, the synthesized instance variable has the same name as the property, but with an underscore prefix. For a property called firstName, for example, the synthesized instance variable will be called _firstName.

Although it’s best practice for an object to access its own properties using accessor methods or dot syntax, it’s possible to access the instance variable directly from any of the instance methods in a class implementation. The underscore prefix makes it clear that you’re accessing an instance variable rather than, for example, a local variable:

– (void)someMethod {

NSString *myString = @”An interesting string”;

_someString = myString;

}

In this example, it’s clear that myString is a local variable and _someString is an instance variable.

In general, you should use accessor methods or dot syntax for property access even if you’re accessing an object’s properties from within its own implementation, in which case you should use self:

– (void)someMethod {

NSString *myString = @”An interesting string”;

self.someString = myString;

// or

[self setSomeString:myString];

}

The exception to this rule is when writing initialization, deallocation or custom accessor methods, as described later in this section.

You Can Customize Synthesized Instance Variable Names

As mentioned earlier, the default behavior for a writeable property is to use an instance variable called _propertyName.

If you wish to use a different name for the instance variable, you need to direct the compiler to synthesize the variable using the following syntax in your implementation:

@implementation YourClass

@synthesize propertyName = instanceVariableName;

…

@end

For example:

@synthesize firstName = ivar_firstName;

In this case, the property will still be called firstName, and be accessible through firstName and setFirstName: accessor methods or dot syntax, but it will be backed by an instance variable called ivar_firstName.

Important: If you use @synthesize without specifying an instance variable name, like this:

@synthesize firstName;

the instance variable will bear the same name as the property.

In this example, the instance variable will also be called firstName, without an underscore.

You Can Define Instance Variables without Properties

It’s best practice to use a property on an object any time you need to keep track of a value or another object.

If you do need to define your own instance variables without declaring a property, you can add them inside braces at the top of the class interface or implementation, like this:

@interface SomeClass : NSObject {

NSString *_myNonPropertyInstanceVariable;

}

…

@end

@implementation SomeClass {

NSString *_anotherCustomInstanceVariable;

}

…

@end

Note: You can also add instance variables at the top of a class extension, as described in Class Extensions Extend the Internal Implementation.

Access Instance Variables Directly from Initializer Methods

Setter methods can have additional side-effects. They may trigger KVC notifications, or perform further tasks if you write your own custom methods.

You should always access the instance variables directly from within an initialization method because at the time a property is set, the rest of the object may not yet be completely initialized. Even if you don’t provide custom accessor methods or know of any side effects from within your own class, a future subclass may very well override the behavior.

A typical init method looks like this:

– (id)init {

self = [super init];

if (self) {

// initialize instance variables here

}

return self;

}

An init method should assign self to the result of calling the superclass’s initialization method before doing its own initialization. A superclass may fail to initialize the object correctly and return nil so you should always check to make sure self is not nil before performing your own initialization.

By calling [super init] as the first line in the method, an object is initialized from its root class down through each subclass init implementation in order. Figure 3-1 shows the process for initializing an XYZShoutingPerson object.

Figure 3-1 The initialization process

As you saw in the previous chapter, an object is initialized either by calling init, or by calling a method that initializes the object with specific values.

In the case of the XYZPerson class, it would make sense to offer an initialization method that set the person’s initial first and last names:

– (id)initWithFirstName:(NSString *)aFirstName lastName:(NSString *)aLastName;

You’d implement the method like this:

– (id)initWithFirstName:(NSString *)aFirstName lastName:(NSString *)aLastName {

self = [super init];

if (self) {

_firstName = aFirstName;

_lastName = aLastName;

}

return self;

}

The Designated Initializer is the Primary Initialization Method

If an object declares one or more initialization methods, you should decide which method is the designated initializer. This is often the method that offers the most options for initialization (such as the method with the most arguments), and is called by other methods you write for convenience. You should also typically override init to call your designated initializer with suitable default values.

If an XYZPerson also had a property for a date of birth, the designated initializer might be:

– (id)initWithFirstName:(NSString *)aFirstName lastName:(NSString *)aLastName

dateOfBirth:(NSDate *)aDOB;

This method would set the relevant instance variables, as shown above. If you still wished to provide a convenience initializer for just first and last names, you would implement the method to call the designated initializer, like this:

– (id)initWithFirstName:(NSString *)aFirstName lastName:(NSString *)aLastName {

return [self initWithFirstName:aFirstName lastName:aLastName dateOfBirth:nil];

}

You might also implement a standard init method to provide suitable defaults:

– (id)init {

return [self initWithFirstName:@”John” lastName:@”Doe” dateOfBirth:nil];

}

If you need to write an initialization method when subclassing a class that uses multiple init methods, you should either override the superclass’s designated initializer to perform your own initialization, or add your own additional initializer. Either way, you should call the superclass’s designated initializer (in place of [super init];) before doing any of your own initialization.

You Can Implement Custom Accessor Methods

Properties don’t always have to be backed by their own instance variables.

As an example, the XYZPerson class might define a read-only property for a person’s full name:

@property (readonly) NSString *fullName;

Rather than having to update the fullName property every time the first or last name changed, it would be easier just to write a custom accessor method to build the full name string on request:

– (NSString *)fullName {

return [NSString stringWithFormat:@”%@ %@”, self.firstName, self.lastName];

}

This simple example uses a format string and specifiers (as described in the previous chapter) to build a string containing a person’s first and last names separated by a space.

Note: Although this is a convenient example, it’s important to realize that it’s locale-specific, and is only suitable for use in countries that put a person’s given name before the family name.

If you need to write a custom accessor method for a property that does use an instance variable, you must access that instance variable directly from within the method. For example, it’s common to delay the initialization of a property until it’s first requested, using a “lazy accessor,” like this:

– (XYZObject *)someImportantObject {

if (!_someImportantObject) {

_someImportantObject = [[XYZObject alloc] init];

}

return _someImportantObject;

}

Before returning the value, this method first checks whether the _someImportantObject instance variable is nil; if it is, it allocates an object.

Note: The compiler will automatically synthesize an instance variable in all situations where it’s also synthesizing at least one accessor method. If you implement both a getter and a setter for a readwrite property, or a getter for a readonly property, the compiler will assume that you are taking control over the property implementation and won’t synthesize an instance variable automatically.

If you still need an instance variable, you’ll need to request that one be synthesized:

@synthesize property = _property;

Properties Are Atomic by Default

By default, an Objective-C property is atomic:

@interface XYZObject : NSObject

@property NSObject *implicitAtomicObject; // atomic by default

@property (atomic) NSObject *explicitAtomicObject; // explicitly marked atomic

@end

This means that the synthesized accessors ensure that a value is always fully retrieved by the getter method or fully set via the setter method, even if the accessors are called simultaneously from different threads.

Because the internal implementation and synchronization of atomic accessor methods is private, it’s not possible to combine a synthesized accessor with an accessor method that you implement yourself. You’ll get a compiler warning if you try, for example, to provide a custom setter for an atomic, readwrite property but leave the compiler to synthesize the getter.

You can use the nonatomic property attribute to specify that synthesized accessors simply set or return a value directly, with no guarantees about what happens if that same value is accessed simultaneously from different threads. For this reason, it’s faster to access a nonatomic property than an atomic one, and it’s fine to combine a synthesized setter, for example, with your own getter implementation:

@interface XYZObject : NSObject

@property (nonatomic) NSObject *nonatomicObject;

@end

@implementation XYZObject

– (NSObject *)nonatomicObject {

return _nonatomicObject;

}

// setter will be synthesized automatically

@end

Note: Property atomicity is not synonymous with an object’s thread safety.

Consider an XYZPerson object in which both a person’s first and last names are changed using atomic accessors from one thread. If another thread accesses both names at the same time, the atomic getter methods will return complete strings (without crashing), but there’s no guarantee that those values will be the right names relative to each other. If the first name is accessed before the change, but the last name is accessed after the change, you’ll end up with an inconsistent, mismatched pair of names.

This example is quite simple, but the problem of thread safety becomes much more complex when considered across a network of related objects. Thread safety is covered in more detail in Concurrency Programming Guide.

Manage the Object Graph through Ownership and Responsibility

As you’ve already seen, memory for Objective-C objects is allocated dynamically (on the heap), which means you need to use pointers to keep track of an object’s address. Unlike scalar values, it’s not always possible to determine an object’s lifetime by the scope of one pointer variable. Instead, an object must be kept active in memory for as long as it is needed by other objects.

Rather than trying to worry about managing the lifecycle of each object manually, you should instead think about the relationships between objects.

In the case of an XYZPerson object, for example, the two string properties for firstName and lastName are effectively “owned” by the XYZPerson instance. This means they should stay in memory as long as the XYZPerson object stays in memory.

When one object relies on other objects in this way, effectively taking ownership of those other objects, the first object is said to have strong references to the other objects. In Objective-C, an object is kept alive as long as it has at least one strong reference to it from another object. The relationships between the XYZPerson instance and the two NSString objects is shown in Figure 3-2.

Figure 3-2 Strong Relationships

When an XYZPerson object is deallocated from memory, the two string objects will also be deallocated, assuming there aren’t any other strong references left to them.

To add a little more complexity to this example, consider the object graph for an application like that shown in Figure 3-3.

Figure 3-3 The Name Badge Maker application

When the user clicks the Update button, the badge preview is updated with the relevant name information.

The first time a person’s details are entered and the update button clicked, the simplified object graph might look like Figure 3-4.

Figure 3-4 Simplified object graph for initial XYZPerson creation

When the user modifies the person’s first name, the object graph changes to look like Figure 3-5.

Figure 3-5 Simplified object graph while changing the person’s first name

The badge display view maintains a strong relationship to the original @"John" string object, even though the XYZPerson object now has a different firstName. This means the @"John" object stays in memory, used by the badge view to print the name.

Once the user clicks the Update button a second time, the badge view is told to update its internal properties to match the person object, so the object graph looks like Figure 3-6.

Figure 3-6 Simplified object graph after updating the badge view

At this point, the original @"John" object no longer has any strong references to it, so it is removed from memory.

By default, both Objective-C properties and variables maintain strong references to their objects. This is fine for many situations, but it does cause a potential problem with strong reference cycles.

Avoid Strong Reference Cycles

Although strong references work well for one-way relationships between objects, you need to be careful when working with groups of interconnected objects. If a group of objects is connected by a circle of strong relationships, they keep each other alive even if there are no strong references from outside the group.

One obvious example of a potential reference cycle exists between a table view object (UITableView for iOS and NSTableView for OS X) and its delegate. In order for a generic table view class to be useful in multiple situations, it delegates some decisions to external objects. This means it relies on another object to decide what content it displays, or what to do if the user interacts with a specific entry in the table view.

A common scenario is that the table view has a reference to its delegate and the delegate has a reference back to the table view, as shown in Figure 3-7.

Figure 3-7 Strong references between a table view and its delegate

A problem occurs if the other objects give up their strong relationships to the table view and delegate, as shown in Figure 3-8.

Figure 3-8 A strong reference cycle

Even though there is no need for the objects to be kept in memory—there are no strong relationships to the table view or delegate other than the relationships between the two objects—the two remaining strong relationships keep the two objects alive. This is known as a strong reference cycle.

The way to solve this problem is to substitute one of the strong references for a weak reference. A weak reference does not imply ownership or responsibility between two objects, and does not keep an object alive.

If the table view is modified to use a weak relationship to its delegate (which is how UITableView and NSTableView solve this problem), the initial object graph now looks like Figure 3-9.

Figure 3-9 The correct relationship between a table view and its delegate

When the other objects in the graph give up their strong relationships to the table view and delegate this time, there are no strong references left to the delegate object, as shown in Figure 3-10.

Figure 3-10 Avoiding a strong reference cycle

This means that the delegate object will be deallocated, thereby releasing the strong reference on the table view, as shown in Figure 3-11.

Figure 3-11 Deallocating the delegate

Once the delegate is deallocated, there are no longer any strong references to the table view, so it too is deallocated.

Use Strong and Weak Declarations to Manage Ownership

By default, object properties declared like this:

@property id delegate;

use strong references for their synthesized instance variables. To declare a weak reference, add an attribute to the property, like this:

@property (weak) id delegate;

Note: The opposite to weak is strong. There’s no need to specify the strong attribute explicitly, because it is the default.

Local variables (and non-property instance variables) also maintain strong references to objects by default. This means that the following code will work exactly as you expect:

NSDate *originalDate = self.lastModificationDate;

self.lastModificationDate = [NSDate date];

NSLog(@”Last modification date changed from %@ to %@”,

originalDate, self.lastModificationDate);

In this example, the local variable originalDate maintains a strong reference to the initial lastModificationDate object. When the lastModificationDate property is changed, the property no longer keeps a strong reference to the original date, but that date is still kept alive by the originalDate strong variable.

Note: A variable maintains a strong reference to an object only as long as that variable is in scope, or until it is reassigned to another object or nil.

If you don’t want a variable to maintain a strong reference, you can declare it as __weak, like this:

NSObject * __weak weakVariable;

Because a weak reference doesn’t keep an object alive, it’s possible for the referenced object to be deallocated while the reference is still in use. To avoid a dangerous dangling pointer to the memory originally occupied by the now deallocated object, a weak reference is automatically set to nil when its object is deallocated.

This means that if you use a weak variable in the previous date example:

NSDate * __weak originalDate = self.lastModificationDate;

self.lastModificationDate = [NSDate date];

the originalDate variable may potentially be set to nil. When self.lastModificationDate is reassigned, the property no longer maintains a strong reference to the original date. If there are no other strong references to it, the original date will be deallocated and originalDate set to nil.

Weak variables can be a source of confusion, particularly in code like this:

NSObject * __weak someObject = [[NSObject alloc] init];

In this example, the newly allocated object has no strong references to it, so it is immediately deallocated and someObject is set to nil.

Note: The opposite to __weak is __strong. Again, you don’t need to specify __strong explicitly, because it is the default.

It’s also important to consider the implications of a method that needs to access a weak property several times, like this:

– (void)someMethod {

[self.weakProperty doSomething];

…

[self.weakProperty doSomethingElse];

}

In situations like this, you might want to cache the weak property in a strong variable to ensure that it is kept in memory as long as you need to use it:

– (void)someMethod {

NSObject *cachedObject = self.weakProperty;

[cachedObject doSomething];

…

[cachedObject doSomethingElse];

}

In this example, the cachedObject variable maintains a strong reference to the original weak property value so that it can’t be deallocated as long as cachedObject is still in scope (and hasn’t been reassigned another value).

It’s particularly important to keep this in mind if you need to make sure a weak property is not nil before using it. It’s not enough just to test it, like this:

if (self.someWeakProperty) {

[someObject doSomethingImportantWith:self.someWeakProperty];

}

because in a multi-threaded application, the property may be deallocated between the test and the method call, rendering the test useless. Instead, you need to declare a strong local variable to cache the value, like this:

NSObject *cachedObject = self.someWeakProperty; // 1

if (cachedObject) { // 2

[someObject doSomethingImportantWith:cachedObject]; // 3

} // 4

cachedObject = nil; // 5

In this example, the strong reference is created in line 1, meaning that the object is guaranteed to be alive for the test and method call. In line 5, cachedObject is set to nil, thereby giving up the strong reference. If the original object has no other strong references to it at this point, it will be deallocated and someWeakProperty will be set to nil.

Use Unsafe Unretained References for Some Classes

There are a few classes in Cocoa and Cocoa Touch that don’t yet support weak references, which means you can’t declare a weak property or weak local variable to keep track of them. These classes include NSTextView, NSFont and NSColorSpace; for the full list, see Transitioning to ARC Release Notes.

If you need to use a weak reference to one of these classes, you must use an unsafe reference. For a property, this means using the unsafe_unretained attribute:

@property (unsafe_unretained) NSObject *unsafeProperty;

For variables, you need to use __unsafe_unretained:

NSObject * __unsafe_unretained unsafeReference;

An unsafe reference is similar to a weak reference in that it doesn’t keep its related object alive, but it won’t be set to nil if the destination object is deallocated. This means that you’ll be left with a dangling pointer to the memory originally occupied by the now deallocated object, hence the term “unsafe.” Sending a message to a dangling pointer will result in a crash.

Copy Properties Maintain Their Own Copies

In some circumstances, an object may wish to keep its own copy of any objects that are set for its properties.

As an example, the class interface for the XYZBadgeView class shown earlier in Figure 3-4 might look like this:

@interface XYZBadgeView : NSView

@property NSString *firstName;

@property NSString *lastName;

@end

Two NSString properties are declared, which both maintain implicit strong references to their objects.

Consider what happens if another object creates a string to set as one of the badge view’s properties, like this:

NSMutableString *nameString = [NSMutableString stringWithString:@”John”];

self.badgeView.firstName = nameString;

This is perfectly valid, because NSMutableString is a subclass of NSString. Although the badge view thinks it’s dealing with an NSString instance, it’s actually dealing with an NSMutableString.

This means that the string can change:

[nameString appendString:@”ny”];

In this case, although the name was “John” at the time it was originally set for the badge view’s firstName property, it’s now “Johnny” because the mutable string was changed.

You might choose that the badge view should maintain its own copies of any strings set for its firstName and lastName properties, so that it effectively captures the strings at the time that the properties are set. By adding a copy attribute to the two property declarations:

@interface XYZBadgeView : NSView

@property (copy) NSString *firstName;

@property (copy) NSString *lastName;

@end

the view now maintains its own copies of the two strings. Even if a mutable string is set and subsequently changed, the badge view captures whatever value it has at the time it is set. For example:

NSMutableString *nameString = [NSMutableString stringWithString:@”John”];

self.badgeView.firstName = nameString;

[nameString appendString:@”ny”];

This time, the firstName held by the badge view will be an unaffected copy of the original “John” string.

The copy attribute means that the property will use a strong reference, because it must hold on to the new object it creates.

Note: Any object that you wish to set for a copy property must support NSCopying, which means that it should conform to the NSCopying protocol.

Protocols are described in Protocols Define Messaging Contracts. For more information on NSCopying, see NSCopying or the Advanced Memory Management Programming Guide.

If you need to set a copy property’s instance variable directly, for example in an initializer method, don’t forget to set a copy of the original object:

– (id)initWithSomeOriginalString:(NSString *)aString {

self = [super init];

if (self) {

_instanceVariableForCopyProperty = [aString copy];

}

return self;

}

Exercises

Modify the sayHello method from the XYZPerson class to log a greeting using the person’s first name and last name.
Declare and implement a new designated initializer used to create an XYZPerson using a specified first name, last name and date of birth, along with a suitable class factory method.Don’t forget to override init to call the designated initializer.
Test what happens if you set a mutable string as the person’s first name, then mutate that string before calling your modified sayHello method. Change the NSString property declarations by adding the copy attribute and test again.
Try creating XYZPerson objects using a variety of strong and weak variables in the main() function. Verify that the strong variables keep the XYZPerson objects alive at least as long as you expect.In order to help verify when an XYZPerson object is deallocated, you might want to tie into the object lifecycle by providing a dealloc method in the XYZPerson implementation. This method is called automatically when an Objective-C object is deallocated from memory, and is normally used to release any memory you allocated manually, such as through the C malloc() function, as described in Advanced Memory Management Programming Guide.For the purposes of this exercise, override the dealloc method in XYZPerson to log a message, like this:- (void)dealloc { NSLog(@”XYZPerson is being deallocated”);}Try setting each XYZPerson pointer variable to nil to verify that the objects are deallocated when you expect them to be.Note: The Xcode project template for a Command Line Tool use an @autoreleasepool { } block inside the main() function. In order to use the Automatic Retain Count feature of the compiler to handle memory management for you, it’s important that any code you write in main() goes inside this autorelease pool block.Autorelease pools are outside the scope of this document, but are covered in detail in Advanced Memory Management Programming Guide.When you’re writing a Cocoa or Cocoa Touch application rather than a command line tool, you won’t usually need to worry about creating your own autorelease pools, because you’re tying into a framework of objects that will ensure one is already in place.
Modify the XYZPerson class description so that you can keep track of a spouse or partner.You’ll need to decide how best to model the relationship, thinking carefully about object graph management.

LEARN MORE

At a Glance

An App Is Built from a Network of Objects

Categories Extend Existing Classes

Protocols Define Messaging Contracts

Values and Collections Are Often Represented as Objective-C Objects

Blocks Simplify Common Tasks

Error Objects Are Used for Runtime Problems

Objective-C Code Follows Established Conventions

Prerequisites

See Also

Defining Classes

Classes Are Blueprints for Objects

Mutability Determines Whether a Represented Value Can Be Changed

Classes Inherit from Other Classes

The Root Class Provides Base Functionality

The Interface for a Class Defines Expected Interactions

Basic Syntax

Properties Control Access to an Object’s Values

Property Attributes Indicate Data Accessibility and Storage Considerations

Method Declarations Indicate the Messages an Object Can Receive

Methods Can Take Parameters

Class Names Must Be Unique

The Implementation of a Class Provides Its Internal Behavior

Basic Syntax

Implementing Methods

Objective-C Classes Are also Objects

Exercises

Working with Objects

Objects Send and Receive Messages

Use Pointers to Keep Track of Objects

You Can Pass Objects for Method Parameters

Methods Can Return Values

Objects Can Send Messages to Themselves

Objects Can Call Methods Implemented by Their Superclasses

Objects Are Created Dynamically

Initializer Methods Can Take Arguments

Class Factory Methods Are an Alternative to Allocation and Initialization

Use new to Create an Object If No Arguments Are Needed for Initialization

Literals Offer a Concise Object-Creation Syntax

Objective-C Is a Dynamic Language

Determining Equality of Objects

Working with nil

Exercises

Encapsulating Data

Properties Encapsulate an Object’s Values

Declare Public Properties for Exposed Data

Use Accessor Methods to Get or Set Property Values

Dot Syntax Is a Concise Alternative to Accessor Method Calls

Most Properties Are Backed by Instance Variables

You Can Customize Synthesized Instance Variable Names

You Can Define Instance Variables without Properties

Access Instance Variables Directly from Initializer Methods

The Designated Initializer is the Primary Initialization Method

You Can Implement Custom Accessor Methods

Properties Are Atomic by Default

Manage the Object Graph through Ownership and Responsibility

Avoid Strong Reference Cycles

Use Strong and Weak Declarations to Manage Ownership

Use Unsafe Unretained References for Some Classes

Copy Properties Maintain Their Own Copies

Exercises