Objective-C Programming/in depth

Now that you have familiarised yourself with the basics of writing a class (you should now be able to construct a simple class or two, and manipulate them), let's have a look at some of Objective-C's deeper features.

Dynamic typing and binding
This is one of Objective-C's strongest features, and allows for greater flexibility and simplicity.

Let's look at something we only glossed over before: the type id.

The id type
Objective-C provides a special type that can hold a pointer to any object you can construct with Objective-C—regardless of class. This type is called id, and can be used to make your Objective-C programming generic.

Let's look at an example of what is known as a container class, that is, a class that is used to hold an object, perhaps in a certain data structure.

Say our container class is a linked list, and we have a linked list of LinkedListNode objects. We don't know what data we might put into the linked list, so this suggests that we might use an id as a central data type. Our interface then might look like This means that we could store any class of object in any linked list node, and we would be able to recover them from the node as easily.

Consequences
Keeping with the previous example, say we have a linked list of Document objects. Say now, we want to calculate the word count of each document in the list, by means of a wordCount method.

But, since an id type can hold a pointer to any object, how do we know that the object has the <tt>wordCount</tt> method defined? How do we know that what we are getting out is indeed a <tt>Document</tt>?

We could merely declare different classes for lists containing <tt>Documents</tt>, or lists containing other types, but this duplicates a lot of functionality, which is not the best practice and we lose the generic nature of our <tt>LinkedListNode</tt> class.

Objective-C provides you with many different solutions to this problem.

Dynamic binding
Say that our linked list doesn't just contain <tt>Document</tt>s, but has also <tt>Spreadsheet</tt> and <tt>Chart</tt> objects as well. Let's assume all these objects have a <tt>title</tt> method defined, but implemented differently. Since at the core of <tt>LinkedListNode</tt> is the <tt>id</tt> class, how would we know which <tt>title</tt> method will be called when we pull out an object from our linked list? Will it be <tt>Document</tt>'s? Or <tt>Chart</tt>'s? Dynamic binding is a solution to this problem.

Dynamic binding means that when we call a certain object's method, and there are several implementations of that method, the right one is figured out at runtime. In Objective-C, this idea is used, but is also extended - you are permitted to send any message to any object. At first glance this may sound rather dangerous, but in fact this allows you a lot of flexibility.

Let's return to our example. We want to print out all the titles of the objects in the linked list, based on their <tt>title</tt> method. Dynamic binding means that the right method to be called (<tt>Documents</tt>'s, <tt>Spreadsheet</tt>'s, or <tt>Chart</tt>'s <tt>title</tt> method) will be figured out at runtime, and we can simply have a loop in the form Dynamic binding is fine for certain circumstances, and can make some other code unexpectedly clearer. However, other circumstances may require more than just this. I want to say more but this is all basics for dynamic binding.

isKindOfClass
Say we are not assured that the objects we place into the <tt>LinkedListNode</tt>s are not all <tt>Document</tt>s. If we have, for example, a <tt>Chart</tt> object in one of the nodes, and it doesn't have <tt>wordCount</tt> defined (in Objective-C terminology, we say that <tt>Chart</tt> objects do not respond to <tt>wordCount</tt>), and we try and do something like:

this would produce a runtime error when <tt>p</tt> points to the node containing the <tt>Chart</tt> object, because <tt>Chart</tt> doesn't respond to the <tt>wordCount</tt> message. We ask the <tt>Chart</tt> to give us a word count, but it doesn't know what to do! In Objective-C, in this example, <tt>Chart</tt> or any other object can do two things: We'll look at the second situation in the next section. So, in this instance, the program fails and reports an error.
 * 1) fail, and report the error, or
 * 2) send the message on to another object to handle.

For this instance, the best Objective-C feature for now, is to use <tt>Object</tt>'s <tt>isKindOfClass:</tt> method. We can add the following check, to get:

This loop will skip over the <tt>Chart</tt> object in this instance. The class method, <tt>class</tt>, returns a class object. The type <tt>Class</tt> is a special type that can hold a pointer to any class object (similar to how <tt>id</tt> can hold a pointer to any object). The instance method <tt>class</tt> also returns the class object for the class of the object. This means that if we wrote the test as <tt>[p class] == [Document class]</tt>, we could test whether the object's class is exactly <tt>Document</tt>. We could also achieve this result using <tt>[p isMemberOfClass:[Document class]]</tt>. This contrasts with <tt>[p isKindOfClass:[Document class]]</tt>, which will check if the object is that class or any of its subclasses (since, due to inheritance, any instance of a subclass "is a" instance of the superclass too). In most cases, <tt>isKindOfClass:</tt> is the better way to test whether an object is an instance of a class.

This sort of behaviour is a way that polymorphism is implemented in Objective-C. Polymorphism is a feature of methods that can be applied to different types, which could have different behaviour when applied to those types.

This sort of behaviour can, of course, become unwieldy when used improperly. Objective-C gives you, however, ways of addressing this. We can either make sure that all objects that we may want to work on have a predefined set of methods implemented, by using what is known as a protocol, or we can "tack on" extra methods to the class, to eliminate this redundant checking, by using what is known as a category. Let's look at protocols first.

Protocols
Spies and secret agents must need to make themselves known to other agents, in order to collect information from others. However, the agents must know whether the other spy or agent is really on their side—the bad guys could send a fake spy in to give the other spies false information! So some form of authentication is usually used, such as a password or a passphrase, or a secret handshake, or they may meet at a certain pre-arranged location. All these are examples of protocols to establish whether a person is trustworthy enough.

Objective-C uses protocols in exactly the same manner. An <tt>id</tt> holds any object—we want to make sure that if we call some method upon the contents of an <tt>id</tt> variable, it is guaranteed to respond to it.

A protocol, in Objective-C, is a list of method declarations that any class that wishes to adopt the protocol must implement.

We write a protocol in a similar way to writing an <tt>@interface</tt> declaration. Here is one typical protocol. Note that we can call the protocol the same as a class—this is okay. It may be useful to place this <tt>Document</tt> protocol in the same header as the <tt>Document</tt> class, or we may want to keep it in a separate file.

If we want to signify that the <tt>Document</tt> class adheres (or is said to conform, in Objective-C) to the <tt>Document</tt> protocol, we must say this in the <tt>@interface</tt> declaration. We do this by writing The <tt><Document></tt> means that the interface to the <tt>Document</tt> class adheres to the <tt>Document</tt> protocol.

Let's revisit our <tt>LinkedListNode</tt> class. Recall we wanted to get the sum of all the words in each document. But, in our <tt>LinkedListNode</tt> class, the core datatype is an <tt>id</tt>. There are basically no restrictions on what we can put into an <tt>id</tt> variable. Ideally, what we'd like to do is say something along the lines of "all objects that adhere to the X, Y or Z protocol". We use angle brackets again to specify this.

Let's create a new class, call it <tt>LinkedListDocument</tt>. This class only has in each node an object that conforms to the <tt>Document</tt> protocol. Instead of saying <tt>id data</tt> in the interface, we say instead:

In order to use the protocol in the type specification, or in the interface specification, we must import the header file in which the protocol is defined.

"Inheritance" of protocols
A protocol can incorporate other protocols that have been defined, in a similar way to inheritance, but there is no hierachy imposed upon protocols like there are in classes. For example, in the <tt>Document</tt> protocol, we could write it this way instead: This allows us to structure and compartmentalize our protocols at a greater level. However, note that a protocol's method declarations can be empty! This means that we can use "empty" protocols to mark or group certain objects based on a higher level than merely what methods the conforming objects respond to (for example, creating an "empty" <tt>GraphicsBased</tt> or <tt>TextBased</tt> protocol in order to set the printer mode, which <tt>Document</tt>, <tt>Spreadsheet</tt>, or <tt>Chart</tt> objects could adopt).

conformsTo
Say we now want to write an <tt>addDocument:</tt> method to our <tt>LinkedListDocument</tt> class. We could write something like which means that any object we must pass in to the <tt>addDocument</tt> method must conform to the <tt>Document</tt> protocol. This may be a little restrictive. We may want to have a declaration like

and return <tt>NO</tt> when the new document doesn't conform to the <tt>Document</tt> protcol, for instance. How can we do this? We may want something that works a little like <tt>isKindOfClass:</tt>. Objective-C provides us with a method <tt>conformsTo:</tt> for just this purpose. We can then write <tt>addDocument:</tt> like

Note the <tt>@protocol(Document)</tt> symbol. This acts in just the same way as <tt>[Document class]</tt> does, except that <tt>@protocol(Document)</tt> returns a <tt>Protocol</tt> object instead of a class object.

If we however have a protocol, and we want to test whether it incorporates another protocol, we can use <tt>conformsTo:</tt> as well. For example, given the protocols above ("Inheritance" of protocols), would give <tt>YES</tt> as a result.


 * In Java, the keyword "interface" means the same as "protocol" in Objective-C . Objective-C uses "interface" to define a declaration for a class, as in "C++" , so the declaration can be used in header files which can be included in client source files for use. The older C++ and Objective-C do not separate the concerns of defining storage layout and function address tables , so an Objective-C "interface" can only be used for one implementation file , whereas in Java, only non-storage declarations such as constants and function names and inner interfaces are defined in interface definitions, so these can be reused amongst various implementation classes. The C++ equivalent of a protocol is a abstract class , where in the declaration definition, all the functions end with " = 0;" . In C++,  object implementations of abstract classes can't be received as copy constructed parameters via functions , but can be received as abstract class pointers. In Objective-C , every object made by calling alloc on a class and instantiated with a init function is returned as a pointer to an object , and there seems to be no mechanism for automatic allocation and deallocation on the stack in a function scope , as occurs with non-pointer variable declarations within the body of a function, as in C++.  Java also follows the objective-C lead of only allowing object creation via the "new" keyword and a constructor .  In Java, interfaces are regarded as a kind of superclass relationship, so "X.class.isAssignableFrom(o)" can be used to test for conformance of an object o to a  interface  X.

Categories
Let's return now to our previous example, where we have <tt>LinkedListNode</tt>s which do not contain only <tt>Document</tt>s. We want to get the sum of all the words in all the <tt>Document</tt>s in the linked list. Recall our previous solution that we added a check

However, this sort of check isn't quite the best solution, on a couple of levels. If we've only got <tt>Document</tt>, <tt>Spreadsheet</tt>, and <tt>Chart</tt> objects, and neither <tt>Spreadsheet</tt> nor <tt>Chart</tt> objects have a way of providing a word count, then, in essence, their word count could be said to be 0. What we want to do, now, is somehow "stick on" a small implementation of <tt>wordCount</tt> that simply returns 0 for objects that have no word count, and then we can remove the check that we have before and merely let dynamic binding do it's work.

Categories provide this way of "sticking on" extra methods, as an alternative to subclassing. What categories do, is a way of building up a class based on separate pieces that are logically grouped together, for example, by category (hence the name).

So, how do we define a category? We write it in a similar form to the <tt>@interface</tt> declaration, but we do this separately.

Here's an example of a <tt>WordCount</tt> category, on the <tt>Spreadsheet</tt> class. We first create an interface for the category: which goes into a header file, and then the implementation of the category

which can go in a <tt>.m</tt> file. Importing the category's header file means that the category is being used. We can do a similar procedure for <tt>Chart</tt> or any other object we need to add a category to.

Now, <tt>Spreadsheet</tt> or any other object that has this category, now has a valid <tt>wordCount</tt> method defined upon it (albeit a simple stub method, but we can do anything we like otherwise), so writing the loop

will be successful since if <tt>[p data]</tt> returns a <tt>Spreadsheet</tt>, the <tt>wordCount</tt> method will be used.

Note: methods declared in categories override preexisting methods. This means that we can do some neat tricks (see the Advantages section below). Also beware that the behaviour in picking a method declared in two categories is undefined.

Advantages of categories
Categories allow us to split up a large class into several pieces. Each can be developed and created independently, and then brought together at the end to form the class.

As a consequence however, this allows us some nice advantages. We can, in essence, extend the functionality of any class that may fall into our hands, whether it is in a class you create yourself, or in a binary form, such as in the OPENSTEP/Cocoa/GNUstep frameworks, we can add a category to <tt>NSString</tt> to provide functionality that the original <tt>NSString</tt> did not provide. It is possible to even add categories to <tt>Object</tt>! Categories can also be used to override previous functionality, which allows us then to "patch" these preexisting classes also, which might be provided with a bug. However, this should be done carefully and only as necessary.

A word on categories
And to finish off this section, let's hear some words of wisdom about categories:
 * What is truly relevant and exciting is how naturally logic is shifted to the appropriate class. Any time Objective-C code looks at the class of an object (using the -isKindOfClass: [isKindOf] method), it is likely that there exists a better, more efficient implementation using categories. This can be generalized with a design heuristic: "Let the runtime do the work of deciding the class of an object". By using the runtime effectively, a developer can often remove some if/then and most case statements. The benefit is obvious: simpler, cleaner code and better performance, since the runtime is optimized for this task.

example of polymorphism to eliminate if..then and switch..case type testing
Elimination of case statements using polymorphic child classes of a base type or category is mundanely shown in this example:

During runtime of a Snake touchscreen game, a user changes the state of the Snake by touching the screen. The snake object has 4 properties of East, West, North, and South MovementAndResponseState objects, all which have a reference to the owning Snake object and can access needed properties of the Snake object. The MovementAndResponseState class is composed of a MovementCategory and ResponseCategory, the movement category handles the movement of the snake in a particular direction by determining the next position on the snake's list of positions, and the response category handles the response to touch, by determining which of East, West, North, or South properties should be the Current direction property of the Snake object, in response to a user touch event. The snake object would have the following delegate pattern:-

The generalization is that in applications that respond to arbitrary user input and are event driven, alternatives exist to the main window loop with a massive case statement that type tests which event type occurred and dispatches to custom handling code.


 * " http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows " describes the venerable message loop-and-case-statements, and mentions frameworks later hiding this stuff, e.g. having GUI designers that link the handler code to a designed graphical element ala delphi-style properties, cocoa-style arrow dragging between designer editor and program text editor, or per-gui-control-object observer pattern "addXXXListener" callback registries , as in sun java's awt and swing frameworks and eclipse swt framework.