Shannon Carver's List: OS X Development

• The message  expression is on the right side of the assignment, enclosed by the square  brackets. The left-most item in the message expression is the receiver, a  variable or expression representing the object to which the message is sent. In  this case, the receiver is sorted_args, an instance of the NSArray class. Following the receiver is the message  proper, in this case objectEnumerator. (For now, we are going to focus on  message syntax and not look too deeply into what this and other messages in  SimpleCocoaTool actually do.) The message objectEnumerator invokes  a method of the sorted_args object named  objectEnumerator, which returns a reference to an object that is  held by the variable enm on the left side of the assignment. This  variable is statically typed as an instance of the NSEnumerator class. You can diagram this statement  as:

  
   

  

  
   

  However, this diagram is simplistic and not really accurate. A message  consists of a selector name  and the parameters of the message. The Objective-C runtime uses a selector name,  such as objectEnumerator above, to look up a selector in a table in  order to find the method to invoke. A selector is a unique identifier that  represents a method and that has a special type, SEL. Because it’s  so closely related, the selector name used to look up a selector is frequently  called a selector as well. The above statement thus is more correctly shown  as:

  
   

  

  
   

  Messages often have parameters, or arguments. A  message with a single argument affixes a colon to the selector name and puts the  argument right after the colon. This construct is called a keyword ; a keyword  ends with a colon, and an argument follows the colon. Thus we could diagram a  message expression with a single argument (and assignment) as the  following:

  
   

  

  
   

  If a message has multiple arguments, the selector has multiple keywords. A  selector name includes all keywords, including colons, but does not include  anything else, such as return type or parameter types. A message expression with  multiple keywords (plus assignment) could be diagrammed as follows:

  
   

  

• Using Objective-C

   

  The way  work gets done in an object-oriented program is through messages; one object  sends a message to another object. Through the message, the sending object  requests something from the receiving object (receiver). It requests that the  receiver perform some action, return some object or value, or do both  things.

   

  Objective-C adopts a unique syntactical form for messaging.  Take the following statement from the SimpleCocoaTool code in Listing  2-2:

   

     

  NSEnumerator *enm = [sorted_args objectEnumerator];

• Objective-C is a very dynamic language. Its dynamism frees a program from compile-time and link-time constraints and shifts much of the responsibility for symbol resolution to runtime, when the user is in control. Objective-C is more dynamic than other programming languages because its dynamism springs from three sources:

  • Dynamic typing—determining the class of an object at runtime

  • Dynamic binding—determining the method to invoke at runtime

  • Dynamic loading—adding new modules to a program at runtime
• The id data type makes it possible to substitute any type of object at runtime. You can thereby let runtime factors dictate what kind of object is to be used in your code. Dynamic typing permits associations between objects to be determined at runtime rather than forcing them to be encoded in a static design. Static type checking at compile time may ensure stricter data integrity, but in exchange for that integrity, dynamic typing gives your program much greater flexibility. And through object introspection (for example, asking a dynamically typed, anonymous object what its class is) you can still verify the type of an object at runtime and thus validate its suitability for a particular operation. (Of course, you can always statically check the types of objects when you need to.)
• Just as dynamic typing defers the resolution of an object’s class membership until runtime, dynamic binding defers the decision of which method to invoke until runtime. Method invocations are not bound to code during compilation, but only when a message is actually delivered. With both dynamic typing and dynamic binding, you can obtain different results in your code each time you execute it. Runtime factors determine which receiver is chosen and which method is invoked.

• Dynamic loading, the final type of dynamism, is a feature of Cocoa that depends on Objective-C for runtime support. With dynamic loading, a Cocoa program can load executable code and resources as they’re needed instead of having to load all program components at launch time. The executable code (which is linked prior to loading) often contains new classes that become integrated into the runtime image of the program. Both code and localized resources (including nib files) are packaged in bundles and are explicitly loaded with methods defined in Foundation’s NSBundle class.

  This “lazy-loading” of program code and resources improves overall performance by placing lower memory demands on the system. Even more importantly, dynamic loading makes applications extensible. You can devise a plug-in architecture for your application that allows you and other developers to customize it with additional modules that the application can dynamically load months or even years after the application is released. If the design is right, the classes in these modules will not clash with the classes already in place because each class encapsulates its implementation and has its own name space.

• With dynamic loading, a Cocoa program can load executable code and resources as they’re needed instead of having to load all program components at launch time. The executable code (which is linked prior to loading) often contains new classes that become integrated into the runtime image of the program. Both code and localized resources (including nib files) are packaged in bundles and are explicitly loaded with methods defined in Foundation’s NSBundle class.

  This “lazy-loading” of program code and resources improves overall performance by placing lower memory demands on the system. Even more importantly, dynamic loading makes applications extensible. You can devise a plug-in architecture for your application that allows you and other developers to customize it with additional modules that the application can dynamically load months or even years after the application is released. If the design is right, the classes in these modules will not clash with the classes already in place because each class encapsulates its implementation and has its own name space.

• Protocols

   

  The Objective-C extension called a protocol is  very much like an interface in Java. Both are simply a list of method  declarations publishing an interface that any class can choose to implement. The  methods in the protocol are invoked by messages sent by an instance of some  other class.

   

  The main value of protocols is that they, like categories, can be an  alternative to subclassing. They yield some of the advantages of multiple  inheritance in C++, allowing sharing of interfaces (if not implementations). A  protocol is a way for a class to declare an interface while concealing its  identity. That interface may expose all or (as is usually the case) only a range  of the services the class has to offer. Other classes throughout the class  hierarchy, and not necessarily in any inheritance relationship (not even to the  root class), can implement the methods of that protocol and so access the  published services. With a protocol, even classes that have no knowledge of  another’s identity (that is, class type) can communicate for the specific  purpose established by the protocol.

   

  There are two types of protocols: formal and informal. Informal  protocols were briefly introduced in “Categories.”  These are categories on NSObject; as a consequence, every object  with NSObject as its root object (as well as class objects)  implicitly adopts the interface published in the category. To use an informal  protocol, a class does not have to implement every method in it, just those  methods it’s interested in. For an informal protocol to work, the class  declaring the informal protocol must get a positive response to a respondsToSelector: message from a target object before  sending that object the protocol message. (If the target object did not  implement the method there would be a runtime exception.)

   

  Formal  protocols are usually what is designated by “protocol” in Cocoa. They allow a  class to formally declare a list of methods that are an interface to a vended  service. The Objective-C language and runtime system supports formal protocols;  the compiler can check for types based on protocols, and objects can introspect  at runtime to verify conformance to a protocol. Formal protocols have their own  terminology and syntax. The terminology is different for provider and  client:

   
   
  •  

    A provider (which usually is a class) declares the formal  protocol.

     
  •  

    A client class adopts a formal protocol, and  by doing so agrees to implement all required methods of the protocol.

     
  •  

    A class is said to conform to a formal protocol if it  adopts the protocol or inherits from a class that adopts it. (Protocols are  inherited by subclasses.)

• Categories

   

  Categories  give you a way to add methods to a class without having to make a subclass. The  methods in the category become part of the class type (within the scope of your  program) and are inherited by all the class’s subclasses. There is no difference  at runtime between the original methods and the added methods. You can send a  message to any instance of the class (or its subclasses) to invoke a method  defined in the category.

   

  Categories are more than a convenient way to add behavior to a class. You can  also use categories to compartmentalize methods, grouping related methods in  different categories. Categories can be particularly handy for organizing large  classes; you can even put different categories in different source files if, for  instance, there are several developers working on the class.

   

  You declare and implement a category much  as you do a subclass. Syntactically, the only difference is the name of the  category, which follows the @interface or  @implementation directive and is put in parentheses. For example,  say you want to add a method to the NSArray class that prints the description of the  collection in a more structured way. In the header file for the category, you  would write declaration code similar to the following:

   

         

  #import <Foundation/NSArray.h> // if Foundation not already imported

  @interface NSArray (PrettyPrintElements)

  - (NSString *)prettyPrintDescription;

  @end

   

  Then in the implementation file you’d write code such as:

   

           

  #import "PrettyPrintCategory.h"

  @implementation NSArray (PrettyPrintElements)

  - (NSString *)prettyPrintDescription {

  // implementation code here...

  }

  @end

   

  There are some limitations to categories. You cannot use a category to  add any new instance variables to the class. Although a category method can  override an existing method, it is not recommended that you do so, especially if  you want to augment the current behavior. One reason for this caution is that  the category method is part of the class’s interface, and so there is no way to  send a message to super to get the behavior already defined by the  class. If you need to change what an existing method of a class does, it is  better to make a subclass of the class.

• Both the declaration and the adoption of a protocol have their own  syntactical forms in Objective-C. To declare a protocol you must use the  @protocol compiler  directive. The following example shows the declaration of the NSCoding protocol (in the Foundation framework’s header  file NSObject.h).

   

        

  @protocol NSCoding

  - (void)encodeWithCoder:(NSCoder *)aCoder;

  - (id)initWithCoder:(NSCoder *)aDecoder;

  @end

   

  Objective-C 2.0 adds a refinement to formal protocols by giving you the  option of declaring optional protocol methods as well as required ones.  In Objective-C 1.0, the adopter of a protocol had to implement all methods of  the protocol. In Objective-C 2.0 protocol methods are still implicitly required,  and can be specifically marked as such using the @required  directive. But you can also mark blocks of protocol methods for optional  implementation using the @optional directive; all methods declared  after this directive, unless there is an intervening @required, can  be optionally implemented. Consider these declarations:

   

                 

  @protocol MyProtocol

  // implementation this method is required implicitly

  - (void)requiredMethod;

  @optional

  // implementation of these methods is optional

  - (void)anOptionalMethod;

  - (void)anotherOptionalMethod;

  @required

  // implementation of this method is required

  - (void)anotherRequiredMethod;

  @end

   

  The class that declares the protocol methods does needs not to implement  them, but it should invoke them in objects of the conforming class. Before  invoking optional methods, it should verify that they’re implemented using the  respondsToSelector: method.

   

  A class adopts a protocol by specifying the protocol, enclosed by angle  brackets, at the end of its @interface directive,  just after the superclass. A class can adopt multiple protocols by delimiting  them with commas. This is how the Foundation NSData class adopts three protocols.

   

     

  @interface NSData : NSObject <NSCopying, NSMutableCopying, NSCoding>

   

  By adopting these protocols, NSData commits itself to  implementing all required methods declared in the protocols. It may also choose  to implement methods marked with the @optional directive.  Categories can also adopt protocols, and their adoption becomes part of the  definition of their class.

   

  Objective-C types classes by the protocols they conform to as well as the  classes they inherit from. You can check if a class conforms to a particular  protocol by sending it a conformsToProtocol: message:

   

       

  if ([anObject conformsToProtocol:@protocol(NSCoding)]) {

  // do something appropriate

  }

   

  In a declaration of a type—a method, instance variable, or function—you can  specify protocol conformance as part of the type. You thus get another level of  type checking by the compiler, one that’s more abstract because it’s not tied to  particular implementations. You use the same syntactical convention as for  protocol adoption: Put the protocol name between angle brackets to specify  protocol conformance in the type. You often see the dynamic object type,  id, used in these declarations, for example:

   

     

  - (void)draggingEnded:(id <NSDraggingInfo>)sender;

   

  Here the object referred to in the argument can be of any class type, but it  must conform to the NSDraggingInfo protocol.

   

  Cocoa provides several examples of protocols other than the ones shown or so  far. An interesting one is the NSObject protocol. Not surprisingly, the NSObject class adopts it, but so does the other root  class, NSProxy. Through the protocol, the NSProxy  class can interact with the parts of the Objective-C runtime essential to  reference counting, introspection, and other basic aspects of object  behavior.

• Declared Properties

   

  In the object modeling design pattern (see “Object  Modeling”) objects have properties.  Properties consist of an object’s attributes, such as title and color, and an  object’s relationships with other objects. In traditional Objective-C code, you  define properties by declaring instance variables and, to enforce encapsulation,  by implementing accessor methods to get and set the values of those variables.  This a tedious and error-prone task, especially when memory management is a  concern (see “Storing  and Accessing Properties”).

   

  Objective-C 2.0, which was introduced in Mac OS X version 10.5, offers a  syntax for declaring properties and specifying how they are to be accessed.  Declaring a property becomes a kind of shorthand for declaring a setter and  getter method for the property. With properties, you no longer have to implement  accessor methods. Direct access to property values is also available through a  new dot-notation syntax. here are three aspects to the syntax of properties:  declaration, implementation, and access.

   

  You can declare properties  wherever methods can be declared in a class, category, or protocol declarative  section. The syntax for declaring properties is:

   
   
  •  

    @property(attributes...)type  propertyName

   

  where attributes are one or more optional attributes (comma-separated  if multiple) that affect how the compiler stores instance variables and  synthesizes accessor methods. The type element specifies an object type,  declared type, or scalar type, such id, NSString *,  NSRange, or float. The property must be backed by an  instance variable of the same type and name.

   

  The possible attributes in  a property declaration are the following:

   
                    

  Attribute	Effect
  getter=getterName   setter=setterName	Specifies the names of getter and setter accessor methods (see “Storing  and Accessing Properties.”) You specify these attributes when you are  implementing your own accessor methods and want to control their  names.
  readonly	Indicates that the property can only be read from, not written to. The  compiler does not synthesize a setter accessor or allow a nonsynthesized one to  be called.
  readwrite	Indicates that the property can be read from and written to. This is the  default if readonly is not specified.
  assign	Specifies that simple assignment should be used in the implementation of the  setter; this is the default. If properties are declared in a  non-garbage-collected program, you must specify retain or  copy for properties that are objects.
  retain	Specifies that retain should be sent to the property (which must be of  an object type) upon assignment. Note that retain is a no-op in a  garbage-collected environment.
  copy	Specifies that copy should be sent to the property (which must be of an  object type) upon assignment. The object’s class must implement the NSCopying protocol.
  nonatomic	Specifies that accessor methods are synthesized as nonatomic. By default, all  synthesized accessor methods are atomic: a  getter method is guaranteed to return a valid value, even when other threads are  executing simultaneously. For a discussion of atomic versus nonatomic  properties, especially with regard to performance, see “Properties“ in The The Objective-C 2.0 Programming Language.

• If you specify no attributes and specify @synthesize for the  implementation, the compiler synthesizes getter and setter methods for the  property that use simple assignment and that have the forms propertyName  for the getter and setPropertyName: for the  setter.

   

  In the @implementation blocks of a class definition, you can use  the @dynamic and and  @synthesize directives to control whether the compiler synthesizes  accessor methods for particular properties. Both directives have the same  general syntax:

   
   
  •  

    @dynamic propertyName [,  propertyName2...];

     
  •  

    @synthesize propertyName [,  propertyName2...];

   

  The @dynamic directive tells the compiler that you are  implementing accessor methods for the property, either directly or dynamically  (such as when dynamically loading code). The @synthesize directive,  on the other hand, tells the compiler to synthesize the getter and setter  methods if they do not appear in the @implementation block. The  syntax for @synthesize also includes an extension that allows you  to name a property differently from its instance-variable storage. Consider, for  example, the following statement:

   
     

  @synthesize title, directReports, role = jobDescrip;

   

  This tells the computer to synthesize accessor methods for properties  title, directReports, and role, and to  use the jobDescrip instance variable to back the role  property.

   

  Finally, the Objective-C properties feature supports a simplified syntax for  accessing  (getting and setting) properties through the use of dot notation and simple  assignment. A few examples suffice to show how easy it is to get the values of  properties and set them using this syntax:

   
        

  NSString *title = employee.title; // assigns employee title to local variable

  employee.ID = "A542309"; // assigns literal string to employee ID

  // gets last name of first employee managed by this employee

  NSString *lname = employee.manager.lastName;

   

  Note that dot-notation syntax works only for attributes and simple one-to-one  relationships, not to-many relationships.

• Fast Enumeration

   

  Fast  enumeration is language feature introduced in Objective-C 2.0 that gives you a  concise syntax for efficient enumeration of collections. It is much faster than  the traditional use of NSEnumerator objects to iterate through arrays, sets, and  dictionaries. Moreover, it ensures safe enumeration by including a mutation  guard to prevent modification of a collection during enumeration. (An exception  is thrown if a mutation is attempted.)

   

  The syntax for fast enumeration is similar to that used in scripting  languages such as Perl and Ruby; there are two supported versions:

   
   
  •  

    for ( type newVariable in  expression ) { statements  }

   

  and

   
   
  •  

    type existingVariable;

     

    for( existingVariable in  expression ) { statements  }

   

  expression must evaluate to an object whose class conforms to the  NSFastEnumeration protocol. The  fast-enumeration implementation is shared between the Objective-C runtime and  the Foundation framework. Foundation declares the NSFastEnumeration protocol, and the Foundation collection  classes—NSArray, NSDictionary, and NSSet—and the NSEnumerator class adopt the  protocol. Other classes that hold collections of other objects, including custom  classes, may adopt NSFastEnumeration to take advantage of this  feature.

   

  The following snippet of code illustrates how you might use fast enumeration  with NSArray and NSSet objects:

   
                   

  NSArray *array = [NSArray arrayWithObjects:

  @"One", @"Two", @"Three", @"Four", nil];

  for (NSString *element in array) {

  NSLog(@"element: %@", element);

  }

  NSSet *set = [NSSet setWithObjects:

  @"Alpha", @"Beta", @"Gamma", @"Delta", nil];

  NSString *setElement;

  for (setElement in set) {

  NSLog(@"element: %@", setElement);

  }
•   

  NSCountedSet *cset = [[NSCountedSet alloc] initWithArray:args];

   

  Here args, which is also an instance of the NSArray  class, is the argument of the message named initWithArray:.

   

  The initWithArray: example cited above is interesting in that  it illustrates nesting. With  Objective-C, you can nest one message inside another message; the object  returned by one message expression is used as the receiver by the message  expression that encloses it. So to interpret nested message expressions, start  with the inner expression and work your way outward. The interpretation of the  above statement would be:

   
   
  1.  

     The alloc message is sent to the NSCountedSet class, which creates (by allocating memory  for it) an uninitialized instance of the class.

      
      

     Note: Objective-C  classes are objects in their own right and you can send messages to them as well  as to their instances. In a message expression, the receiver of a class message  is always a class object.

      

      
  2.  

     The initWithArray: message is sent to the uninitialized  instance, which initializes itself with the array args and returns  a reference to itself.
• 

  
   

  Objective-C uses a number of defined types  and literals that you won’t find in ANSI C. In some cases, these types and  literals replace their ANSI C counterparts. Table  2-1 describes a few of the important ones, including the allowable  literals for each type.

   

               

  Table 2-1  Important Objective-C  defined types and literals

  Type	Description and literal
  id	The dynamic object type. Its negative literal is  nil.
  Class	The dynamic class type. Its negative literal is  Nil.
  SEL	The data type (typedef) of a selector. The negative literal of  this type is NULL.
  BOOL	A Boolean type. The literal values are YES and  NO.

13 more annotations...