View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team extends Good implements Skill Cases

Team extends Good implements Skill

Members:
Adam Allred
Christopher Kramer
Sterling Metz

Using Morphic Model-View Controller to Simplify Implementation.


Why MVC?

If you’ve gone through 2335, you know it can be challenging to make the user interface and the kernel of your system work together. The most important part of this interaction should be your structure. Should the GUI hold the model? Does the model hold the GUI? Is it something in between? Many of these questions are eliminated by the proper use of Model-View Controller.

What is MVC?

MVC stands for Model-View Controller, and is a programming paradigm that aims to completely separate a user interface and its respective model. It makes for compartmentalization of code, delegation of responsibilities, and overall good Object Oriented design. Some of the chief reasons behind the creation of the Object Oriented paradigm were to allow for user interfaces. Think of MVC as the correct OO link of your software's back end to its front end.

The idea behind MVC is that a model of data is held within a program. This model contains the data value, networking, and functionality of your code. If you were going to run the software from the command line, you would be adding some basic stream reading and writing to the model. However it is essential to understand that the model doesn’t care AT ALL about displaying it. A View looks at the data of the model and shows it on screen. It doesn't manipulate your data whatsoever. From a programming perspective the methods in your view code should be basic and just interpret what it is given to them. In Squeak, the idea is taken one step further. Instead of just a paradigm, Squeak lets you actually implement MVC, and provides a way for flawless and extremely easy model/GUI integration.

How can I use MVC?

In order to show you how to use MVC, we’re going to go play Pong, and show how to make it.

PART 1: THE BASIC CLASSES

1. We start with six classes: Ball, BallMorph, PongPlayer, PongPlayerMorph, Pong, and PongMorph.

Uploaded Image: classes.jpg

In this setup, we have two models: Ball and PongPlayer, and their Views: BallMorph and PongPlayerMorph. We’re going to put it all in the PongMorph.

2. The Ball and PongPlayer classes are Model subclasses, so they represent the Model half of our game.

Uploaded Image: models.jpg

3. The The BallMorph and PongPlayerMorph classes are the Views, because they are Morph subclasses, and have lots of features that let them be drawn on screen

PART 2: BASIC STRUCTURE

1. In the MVC setup, you can couple the model and view together by either having the model hold the view, or vice versa. Typically, we found it more sensible for the view to hold the model. Generally, we find our Models more portable than our views, which tend to be redone and tweaked more often. User interface can be a much more fickle beast than the model. In short, for this tutorial, we’ll have the view hold the model, because you normally see the view on the top, while the model is “deep within the system”

Uploaded Image: morphholdingmodel.jpg

Here is a simple little UML of our design, to help out:

UMLPong1.doc

PART 3: THE METHODS

1. Now for the fun part. Within the initialization methods of each Morph (our views), we make the model, and call a VERY important method:

addDependent: self.

This method (and two others, described in a second) is the heart of MVC. It tells the model—in this case, the Ball—that it has a view. This view will look at the named model and display data about it. In this way, we let the view pull data from the model, though the view is never actually participating in any of the processes of the model. In all truth it lets the model's dependents access pertinent information changes. The request from the model really doesn't count as serious interaction. This is being stressed because of the importance of separation between the model and the view in good MVC design.

Uploaded Image: addDependent.jpg

Also, we are not limited to only one dependent for a Model. We could have several views on one model, just by using addDependent multiple times.

2. Now that we’ve added dependents, how do we alert them to changes they need to know? Within each model, you can call the self changed: <type of change> method whenever you need to alert any dependent about changes within the model. Think of this as raising the flag on the side of your mailbox when you put a letter in. You are not really talking to the mailman. You don't have to know him or talk to him. You are just offering a reminder. So, DON’T FORGET THIS! If you do, nothing will happen.

Uploaded Image: selfchanged.jpg

3. Now that we have the model alerting dependents (our views), how do the views respond to this? As it turns out, whenever the model calls self changed: the views get a message called “update” with the <type of change>. Now, depending on the type of change, the view can properly update itself.

Uploaded Image: update.jpg

PART 4: THE MADNESS (of Pong)

Now that we have the Models properly updating themselves, we have a basic MVC system. Add in a few animation methods…

Uploaded Image: animationengine.jpg

As well as a little bit of polar math for calculating movement…

Uploaded Image: polarmath.jpg

Sorry, Just Kidding. I know, we are really lame.


Now we have Pong!

Pong.st
Uploaded Image: pong.jpg

And that’s it! You now have GUI and Model fully interacting. The code is still separated, allowing good reusability. The code is well broken down allowing it to be robust and easily tested. This means that our proper MVC has served its purpose in satisfying good OO design.
UMLPong1.doc
Pong.st

Links to this Page