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.

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.

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.

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.

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;

@interface Person : NSObject

@property (readonly) NSString *firstName;

@property (readonly) NSString *lastName;

@end

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.

void SomeFunction(SomeType value);

- (void)someMethodWithValue:(SomeType)value;

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

someMethodWithFirstValue:secondValue:

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

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.

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.