The Model-View-Controller (MVC) Design Pattern
The iOS frameworks are object oriented. An easy way to understand what that really means is to think about a team working in an office. The work that needs to get done is divided up and assigned to individual team members (in this case, objects). Each team member has a job and works with other team members to get things done.
What’s more, a good team member doesn’t care how other members do their work, just that they do it according to the agreed upon division of labor. Likewise, an object in object-oriented programming takes care of its own business and doesn’t care what the object in the virtual cubicle next door is doing, as long as it will do what it’s supposed to do when asked to do it.
Object-oriented programming was originally developed to make code more maintainable, reusable, extensible, and understandable by encapsulating all the functionality behind well-defined interfaces. The actual details of how something works (as well as its data) are hidden, which makes modifying and extending an application much easier.
Great — so far — but a pesky question still plagues programmers:
Exactly how do you decide on the objects and what each one does?
Sometimes the answer to that question is pretty easy — just use the real world as a model. In a RoadTrip app, for example, some of the classes of model objects are Trip, Events, Destination, and so on. But when it comes to a generic program structure, how do you decide what the objects should be? That may not be so obvious.
The MVC pattern is a well-established way to group application functions into objects. Variations of it have been around at least since the early days of Smalltalk, one of the very first object-oriented languages. The MVC is a high-level pattern — it addresses the architecture of an application and classifies objects according to the general roles they play in an application, rather than drilling down into specifics.
The MVC pattern creates, in effect, a miniature universe for the application, populated with three distinct kinds of objects. It also specifies roles and responsibilities for all three types of objects and specifies the way they’re supposed to interact with each other. To make things more concrete (that is, to keep your head from exploding), imagine a big, beautiful, 60-inch, flat-screen TV. Here’s the gist:
Model objects: These objects together comprise the content “engine” of your app. They contain the app’s data and logic — making your app more than just a pretty face.
You can think of the model (which may be one object or several that interact) as a particular television program, one that, quite frankly, doesn’t give a hoot about what TV set it’s shown on.
In fact, the model shouldn’t give a hoot. Even though it owns its data, it should have no connection to the user interface and should be blissfully ignorant about what’s done with its data.
View objects: These objects display things on the screen and respond to user actions. Pretty much anything you can see is a kind of view object — the window and all the controls, for example.
Your views know how to display information they receive from the model object and how to get any input from the user the model may need. But the view itself should know nothing about the model. It may handle a request to display some events, but it doesn’t bother itself with what that request means.
You can think of the view as a television screen that doesn’t care about what program it’s showing or what channel you just selected.
The UIKit framework provides many different kinds of views, as you find out in the next section.
If the view knows nothing about the model, and the model knows nothing about the view, how do you get data and other notifications to pass from one to the other? To get that conversation started (Model: “I’ve just updated my data.” View: “Hey, give me something to display,” for example), you need the third element in the MVC triumvirate, the controller.
Controller objects: These objects connect the application’s view objects to its model objects. They supply the view objects with what they need to display (getting it from the model) and also provide the model with user input from the view.
You can think of the controller as the circuitry that pulls the show off of the cable and then sends it to the screen or requests a particular pay-per-view show.
The basic application architecture looks like Figure 4-8.
When you think about your application in terms of model, view, and controller objects, the UIKit framework starts to make sense. Understanding the framework this way also begins to lift the fog hanging over where to make at least part of your application-specific behavior go.
Before you delve into that topic, however, you need to know a little more about the classes that the UIKit provides, because these are the guys you will task with implementing the MVC design pattern — window classes, view classes, and view controller classes.
In Objective-C, classes include instance variables, properties, and methods (that can access the instance variables of a class). Classes are about files in your project that contain code. Classes are types in your program.
Objects, on the other hand, exist at runtime and are instances of a class. You can think of a class as a blueprint to build an object of that type.