The Essence of Cocoa

This chapter covers the most common object-oriented design pattern used in Cocoa and shows how that paradigm is applied to application development. A design pattern is a template for a design that solves a general, recurring problem in a particular context. If you have done object-oriented design before, you may be wondering how that model fits into the world of Cocoa. This tutorial will help you understand what Cocoa is as an object-oriented framework. If you’ve done only procedural programming before, don’t worry. This tutorial also teaches the basics of the object-oriented programming. You will learn the MVC design pattern, which is a very common practice used by application developers.

What Is Cocoa?

Cocoa is an object-oriented library of tools that contains many of the objects and methods needed to develop great applications for Mac OS X. By providing these tools to programmers, it takes the tedium out of writing applications. It also makes user interface development simple. If you’ve ever tried to design a user interface by writing the actual code for it, you understand how difficult it is. In this tutorial, you’ll learn how easy it is to create a beautiful user interface by merely dragging objects onto a window.

If you would like more detail on what you can do with Cocoa and how it fits into Mac OS X, see Cocoa Fundamentals Guide.

Classes and Objects

An object consists of both data and methods for manipulating that data. An object is an instance of a class, which means that there is memory allocated for that specific instance of the class. An essential characteristic of objects is that they encapsulate data. Other objects or external code cannot access the object’s data directly, but they request data from the object by sending messages to it. Read that sentence again, as it speaks from the very heart of object-oriented development. Other objects or external code cannot access the object’s data directly, but they request data from the object by sending messages to it. Your job is to make those objects talk to one another and share information through their methods.

An object invokes methods corresponding to messages that are passed to it and may return data to whoever sent the message. An object’s methods do the encapsulating, in effect, regulating access to the object’s data. An object’s methods are also its interface, articulating the ways in which the object communicates with the outside world.

Because an object encapsulates a defined set of data and logic, you can easily assign it to particular duties within a program. Conceptually, it is like a functional unit—for instance, “customer record”—that you can move around on a design board; you can then plot communication paths to and from other objects based on their interfaces.

When designing an object-oriented application, it is often helpful to depict the relationships between objects graphically. This document depicts objects graphically as shown in Figure 1-1.

See The Objective-C Programming Language for a fuller description of data encapsulation, messages, methods, and other things pertaining to object-oriented programming.

The MVC Design Pattern

Model-View-Controller (MVC) is a design pattern that was derived from Smalltalk-80. It proposes three types of objects in an application, separated by abstract boundaries and communicating with each other across those boundaries, as illustrated in Figure 1-2. This is the design pattern behind many designs for object-oriented programs. This design pattern aids in the development of maintainable, extensible, and understandable systems.

Model Objects

This type of object represents special knowledge and expertise. Model objects hold data and define the logic that manipulates that data. For example, suppose you have a customer object, a common object in business applications, that holds all of the salient facts about a customer, including the customer’s name, date of birth, and phone number. That object would be a model object because it represents the data your application manipulates, and has access to methods that can access and distribute that information. A more specialized model might be one in a meteorological system called Front; objects of this type would contain the data and intelligence to represent weather fronts. Model objects are not directly accessed by the user of the application. They are often reusable, distributed, persistent, and portable to a variety of platforms.

View Objects

A view object represents something visible on the user interface (a window or a button, for example). A view object is “ignorant” of the source of the data it displays. The Application Kit, one of the frameworks that Cocoa is composed of, usually provides all the basic view objects you need: windows, text fields, scroll views, buttons, browsers, and so on. But you might want to create your own view objects to show or represent your data in a novel way (for example, a graph view). You can also group view objects within a window in novel ways specific to an application. View objects tend to be very reusable and so provide consistency between applications.

Controller Objects

Acting as mediators between model objects and view objects in an application are controller objects. Controller objects communicate data back and forth between the model and view objects. A controller object, for example, could mediate the transfer of a street address (from the customer model object) to a visible text field on a window (the view object). It also performs all the chores specific to the application it is part of. Since what a controller does is very specific to an application, it is generally not reusable even though it often comprises much of an application’s code. (This last statement does not mean, however, that controller objects cannot be reused; with a good design, they can.) Because of the controller’s central, mediating role, model objects need not know about the state and events of the user interface, and view objects need not know about the programmatic interfaces of the model objects. You can even make your view and model objects available to other developers from a palette in Interface Builder.

Hybrid Models

MVC, strictly observed, is not always the best solution. Sometimes it’s best to combine roles. For instance, in a graphics-intensive application, such as an arcade game, you might have several view objects that merge the roles of view and model. In some applications, especially simple ones, you can combine the roles of controller and model; these objects join the special data structures and logic of model objects with the controller’s hooks to the interface.

The Currency Converter Application

The MVC design pattern, albeit a very simplified one, can be applied directly to the Currency Converter application. Currency Converter is a simple application that converts US dollars to another currency based on an exchange rate entered by the user. Though it’s a very simple application, it can still be used to convey the fundamental elements of Cocoa application development using the MVC design pattern.

The underlying functionality, which is the model, converts US dollars to another currency based on an exchange rate. For this, there is a single function, convertCurrency, which multiplies the amount in US dollars by the exchange rate to get the amount in the other currency.

All graphical applications have a user interface that the user interacts with. This is the view. Here, the user inputs the exchange rate in one text field, the amount of dollars to convert in the next text field, and clicks the convert button, or presses Return, to perform the calculation. The final result appears in the last text box, which is the amount of the other currency.

The view needs to send the data the user entered to the model somehow. This is done by creating a controller, which gathers the exchange rate and amount in US dollars from the view, sends the values to the model, and writes the result into the view.

---