Editing Cocoa (API) (section)

==Model–view–controller==
{{Main article|Model–view–controller}}

The [[Smalltalk]] teams at [[Xerox PARC]] eventually settled on a design philosophy that led to easy development and high code reuse. Named ''[[model–view–controller]]'' (MVC), the concept breaks an application into three sets of interacting object classes:

* Model classes represent problem domain data and operations (such as lists of people/departments/budgets; documents containing sections/paragraphs/footnotes of stylized text).
* View classes implement visual representations and affordances for human-computer interaction (such as scrollable grids of captioned icons and pop-up menus of possible operations).
* Controller classes contain logic that surfaces model data as view representations, maps affordance-initiated user actions to model operations, and maintains state to keep the two synchronized.

Cocoa's design is a fairly, but not absolutely strict application of MVC principles. Under OpenStep, most of the classes provided were either high-level View classes (in AppKit) or one of a number of relatively low-level model classes like NSString. Compared to similar MVC systems, OpenStep lacked a strong model layer. No stock class represented a "document," for instance. During the transition to Cocoa, the model layer was expanded greatly, introducing a number of pre-rolled classes to provide functionality common to desktop applications.

In Mac OS X 10.3, Apple introduced the NSController family of classes, which provide predefined behavior for the controller layer. These classes are considered part of the [[Cocoa Bindings]] system, which also makes extensive use of protocols such as [[Key-Value Observing]] and [[Key-Value Binding]]. The term 'binding' refers to a relationship between two objects, often between a view and a controller. Bindings allow the developer to focus more on declarative relationships rather than orchestrating fine-grained behavior.

With the arrival of Mac OS X 10.4, Apple extended this foundation further by introducing the [[Core Data]] framework, which standardizes change tracking and persistence in the model layer. In effect, the framework greatly simplifies the process of making changes to application data, undoing changes when necessary, saving data to disk, and reading it back in.

In providing framework support for all three MVC domains, Apple's goal is to reduce the amount of boilerplate or "glue" code that developers have to write, freeing up resources to spend time on application-specific features.