12.6 Support for Object-Oriented Programming in Objective-C

clearly a strong argument in favor of C++. Of course, all of the compiled languages that support object-oriented programming are approximately 10 times faster than Smalltalk.

12.6 Support for Object-Oriented Programming in Objective-C

We discuss the support for object-oriented programming in Objective-C relative to that of C++. These two languages were designed at approximately the same time. Both add support for object-oriented programming to the C language. In appearance, the largest difference is in the syntax of method calls, which in C++ are closely related to the function calls of C, whereas in Objective-C they are more similar to the method calls of Smalltalk.

12.6.1General Characteristics

Objective-C, like C#, has both primitive types and objects. Recall that a class definition consists of two parts, interface and implementation. These two parts are often placed in separate files, the interface file using the .h name extension and the implementation using the .m name extension. When the interface is in a separate file, the implementation file begins with the following:

#import "interface_file.h"

Instance variables are declared in a brace-delimited block following the header of the interface section. Objective-C does not support class variables directly. However, a static global variable that is defined in the implementation file can be used as a class variable.

The implementation section of a class contains definitions of the methods declared in the corresponding interface section.

Objective-C does not allow classes to be nested.

12.6.2Inheritance

Objective-C supports only single inheritance. Every class must have a parent class, except the predefined root class named NSObject. One reason to have a single root class is that there are some operations that are universally needed. Among these are the class methods alloc and init. The parent class of a new class is declared in the interface directive after the colon that is attached to the name of the class being defined, as in the following:

@interface myNewClass: NSObject {

Because base class data members can be declared to be private, subclasses are not necessarily subtypes. Of course, all of the protected and public data

members of the parent class are inherited by the subclass. New methods and instance variables can be added to the subclass. Recall that all methods are public, and that cannot be changed. A method that is defined in the subclass and has the same name, same return type, and same number and types of parameters overrides the inherited method. The overridden method can be called in another method of the subclass through super, a reference to the parent object. There is no way to prevent the overriding of an inherited method.

As in Smalltalk, in Objective-C any method name can be called on any object. If the run-time system discovers that the object has no such method (with the proper protocol), an error occurs.

Objective-C does not support the private and protected derivations of C++. As in other languages that support object-oriented programming, the constructor of an instance of a subclass should always call the constructor of the parent class before doing anything else. If the name of the parent class con-

structor is init, this is done with the following statement:

[super init];

Objective-C includes two ways to extend a class besides subclassing: categories and protocols. A collection of methods can be added to a class with a construct called a category. A category is a secondary interface of a class that contains declarations of methods. No new instance variables can be included in the secondary interface. The syntactic form of such an interface is exemplified by the following:

#import "Stack.h"

@interface Stack (StackExtend)

-(int) secondFromTop;

-(void) full;

@end

The name of this category is StackExtend. The original interface is accessible because it is imported, so the parent class need not be mentioned. The new methods are mixed into the methods of the original interface. Consequently, categories are sometimes called mixins. Mixins are sometimes used to add certain functionalities to different classes. And, of course, the class still has a normal superclass from which it inherits members. So, mixins provide some of the benefits of multiple inheritance, without the naming collisions that could occur if modules did not require module names on their functions. Of course, a category must also have an implementation section, which includes the name of the category in parentheses after the class name on the implementation directive, as in the following:

@implementation Stack (StackExtend)

The implementation need not implement all of the methods in the category.

There is another way to provide some of the benefits of multiple inheritance in Objective-C, protocols. Although Objective-C does not provide abstract classes, as in C++, protocols are related to them. A protocol is a list of method declarations. The syntax of a protocol is exemplified with the following:

@protocol MatrixOps

-(Matrix *) add: (Matrix *) mat; -(Matrix *) subtract: (Matrix *) mat;

@optional

-(Matrix *) multiply: (Matrix *) mat; @end

In this example, MatrixOps is the name of the protocol. The add and subtract methods must be implemented by a class that uses the protocol. This use is called implementing or adopting the protocol. The optional part specifies that the multiply method may or may not be implemented by an adopting class.

A class that adopts a protocol lists the name of the protocol in angle brackets after the name of the class on the interface directive, as in the following:

@interface MyClass: NSObject <YourProtocol>

12.6.3Dynamic Binding

In Objective-C, polymorphism is implemented in a way that differs from the way it is done in most other common programming languages. A polymorphic variable is created by declaring it to be of type id. Such a variable can reference any object. The run-time system keeps track of the class of the object to which an id type variable refers. If a call to a method is made through such a variable, the call is dynamically bound to the correct method, assuming one exists.

For example, suppose that a program has classes defined named Circle and Square and both have methods named draw. Consider the following skeletal code:

// Create the objects

Circle *myCircle = [[Circle alloc] init];

Square *mySquare = [[Square alloc] init];

//Initialize the objects [myCircle setCircumference: 5]; [mySquare setSide: 5];

//Create the id variable

id shapeRef;

//Set the id to reference the circle and draw it

inheritance.8 An interface definition is similar to a class definition, except that it can contain only named constants and method declarations (not definitions). It cannot contain constructors or nonabstract methods. So, an interface is no more than what its name indicates—it defines only the specification of a class. (Recall that a C++ abstract class can have instance variables and all but one of the methods can be completely defined.) A class does not inherit an interface; it implements it. In fact, a class can implement any number of interfaces. To implement an interface, the class must implement all of the methods whose specifications (but not bodies) appear in the interface definition.

An interface can be used to simulate multiple inheritance. A class can be derived from a class and implement an interface, with the interface taking the place of a second parent class. This is sometimes called mixin inheritance, because the constants and methods of the interface are mixed in with the methods and data inherited from the superclass, as well as any new data and/or methods defined in the subclass.

One more interesting capability of interfaces is that they provide another kind of polymorphism. This is because interfaces can be treated as types. For example, a method can specify a formal parameter that is an interface. Such a formal parameter can accept an actual parameter of any class that implements the interface, making the method polymorphic.

A nonparameter variable also can be declared to be of the type of an interface. Such a variable can reference any object of any class that implements the interface.

One of the problems with multiple inheritance occurs when a class is derived from two parent classes and both define a public method with the same name and protocol. This problem is avoided with interfaces. Although a class that implements an interface must provide definitions for all of the methods specified in the interface, if the class and the interface both include methods with the same name and protocol, the class need not reimplement that method. So, the method name conflicts that can occur with multiple inheritance cannot occur with single inheritance and interfaces. Furthermore, variable name conflicts are completely avoided because interfaces cannot define variables.

An interface is not a replacement for multiple inheritance, because in multiple inheritance there is code reuse, while interfaces provide no code reuse. This is an important difference, because code reuse is one of the primary benefits of inheritance. Java provides one way to partially avoid this deficiency. One of the implemented interfaces could be replaced by an abstract class, which could include code that could be inherited, thereby providing some code reuse.

One problem with interfaces being a replacement for multiple inheritance is the following: If a class attempts to implement two interfaces and both define methods that have the same name and protocol, there is no way to implement both in the class.

As an example of an interface, consider the sort method of the standard Java class, Array. Any class that uses this method must provide an

8. A Java interface is similar to a protocol in Objective-C.