< Previous PageNext Page >

Using a Cocoa Framework

Library functions impose few restrictions on the programs that use them; you can call them whenever you need to. The methods in an object-oriented library or framework, on the other hand, are tied to class definitions and can’t be invoked unless you create or obtain an object that has access to those definitions. Moreover, in most programs the object must be connected to at least one other object so that it can operate in the program network. A class defines a program component; to access its services, you need to craft it into the structure of your application.

That being said, some framework classes generate instances that behave pretty much as a set of library functions. You simply create an instance, initialize it, and either send it a message to accomplish a task, or you insert it into a waiting slot in your application. For example, you can use the NSFileManager class to perform various file-system operations, such as moving, copying, and deleting files. If you need to display an alert dialog, you would create an instance of the NSAlert class and send it the appropriate message.

In general, however, environments such as Cocoa are more than a grab bag of individual classes that offer their services. They consist of object-oriented frameworks, collections of classes that structure a problem space and present an integrated solution to it. Instead of providing discrete services that you can use as needed (as with function libraries), a framework maps out and implements an entire program structure—or model—that your own code must adapt to. Because this program model is generic, you can specialize it to meet the requirements of your particular program. Rather than design a program that you plug library functions into, you plug your own code into the design provided by the framework.

To use a framework, you must accept the program model it defines and employ and customize as many of its classes as necessary to mold your particular program to that model. The classes are mutually dependent and come as a group, not individually. At first glance, the need to adapt your code to a framework’s program model might seem restrictive. But the reality is quite the opposite. A framework offers you many ways in which you can alter and extend its generic behavior. It simply requires you to accept that all Cocoa programs behave in the same fundamental ways because they are all based on the same program model.

In this section:

Kinds of Framework Classes
Cocoa API Conventions


Kinds of Framework Classes

The classes in a Cocoa framework deliver their services in four ways:

Some classes provide more than one of these general kinds of services. For example, you can drag a ready-made NSWindow object from an Interface Builder palette and use it with only minor initializations. Thus the NSWindow class provides off-the-shelf instances. But an NSWindow object also sends messages to its delegate and posts a variety of notifications. You can even subclass NSWindow if, for example, you want to have round windows.

It is the Cocoa classes in the last two categories—generic and delegator/notifier—that offer the most possibilities for integrating your program-specific code into the structure provided by the frameworks. “Inheriting From a Cocoa Class” discusses in general terms how you create subclasses of framework classes, particularly generic classes. See “Communicating With Objects” for information on delegation, notification, and other mechanisms for communication between objects in a program network.

Cocoa API Conventions

When you start using the classes, methods, and other API of the Cocoa frameworks, you should be aware of a few conventions that are intended to ensure efficiency and consistency in usage.

A substantial subset of Cocoa API conventions concerns the naming of classes, methods, functions, constants, and other symbols. You should be aware of these conventions when you begin designing your own programmatic interfaces. Some of the more important of these naming conventions are the following:

For the complete set of naming guidelines for Objective-C programmatic interfaces, see Coding Guidelines for Cocoa.

A general, overarching API convention regards object ownership. Briefly stated, the convention is that a client owns an object if it creates the object (by allocation then initialization), copies it, or retains it (by sending it retain). An owner of an object is responsible for its disposal by sending release or autorelease to the object when it no longer needs it. For more on this subject, see “The Life Cycle of a Cocoa Object” and Memory Management Programming Guide for Cocoa.



< Previous PageNext Page >


© 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-12-20)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.