Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL
Help

Chapter 29. Controllers > Solution - Pg. 270

Chapter 29. Controllers Within the overarching Model View Controller (MVC) design pattern, the Controller subsystem has historically lagged the other subsystems when it comes to object reuse. Controller subsystems are full of "glue" code used to mediate between views and models. In contrast, the Model and View subsystems are replete with standard reuse scenarios. Mature flexible data structures, databases, and algorithms for models were well established decades ago. Standard reusable view objects shipped with the earliest ancestors of Cocoa in 1988 complete with Interface Builder. The Application Kit leverages patterns to almost automate the development of View subsystems. But what about controllers? How are design patterns applied to simplify controllers, promote wide scale controller reuse, and automate controller development? The Controller subsystem in Cocoa has only lately matured and standardized, and the only real explanation for the delay is that it has taken longer to recognize the design patterns that are applicable for controllers. Consider how controllers differ from views. Conventions and metaphors for user interaction with views are now standard. For example, users understand the concept of the "current selection" within a user interface and that using the "Copy" menu item will copy the current selection and not some other part of the interface. The metaphors and conventions for views had to be established before design patterns like Cocoa's Responder Chain were applied to implement those conventions. Conventions and metaphors for controllers are less clear. Con- trollers integrate views with models as diverse as games, employee benefits management, weather simulations, and robotic arm manipulation. This chapter explores some common controller tasks and identifies opportunities for reuse in "glue" code. In the process, this chapter exposes the rationale for the various Cocoa NSController subclasses and the resulting design patterns. Motivation Reduce the need for recurring error prone code when implementing the Controller subsystem of the Model View Controller design pattern. Apply Apple's Interface Builder tool and the Controllers pattern to streamline development of the Controller subsystem for simple applications and substantially reduce the code needed to implement complex applications. Solution This section presents the relatively simple MVC MYShapeDraw application example shown in Figure 29.1. The example highlights typical tasks a Controller subsystem needs to perform. Initially, the entire implementation of MYShapeDraw 's controller subsystem is in just one class. The example includes the kind of code that has historically been written and rewritten for almost every MVC application. Once the MYShapeDraw application is fully developed, the example's controller is redesigned to make it more general and reusable. By the end of this section, the example's Controller subsystem evolves into a clone of the design used by Cocoa's NSArray- Controller class. Following the step-by-step reinvention of NSArrayController in this chapter reveals why Cocoa's NSObjectController and its subclasses exist and how they're used in applications. 270