This is not an introduction to the MVC pattern, but a look into its implementation in Smalltalk-80 to understand the original intent and function of the Model, View, and Controller triad. Starting with the “classic” MVC helped me understand the evolution of the presentation patterns that came after it. We will look at how a simple MVC app works in Smalltalk-80 and examine how it can be implemented in ActionScript. I am not a Smalltalk programmer and my first task was to find some good resources.
Trygve Reenskaug is credited with the first MVC formulation in Smalltalk in the late 70’s. However, the MVC metaphor was burned into Smalltalk and matured after Reenskaug left Xerox Parc. I found two useful resources on MVC in Smalltalk-80. The first is A cookbook for using the model-view controller user interface paradigm in Smalltalk-80 by Glenn Krasner and Stephen Pope. The second resource is Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC) by Steve Burbeck.
Although comprehensive, Krasner and Pope’s article is very readable from an ActionScript perspective. I could just about follow the Smalltalk code listings, identify the early OOP features and appreciate the ancestors of contemporary UI components. What stood out was how little things have changed in the last 20 to 30 years in OOP and GUI programming. I think the more appropriate observation is how advanced Smalltalk was for its time. Krasner and Pope’s essay is the primary resource for this post.
Model-View-Controller Implementation in Smalltalk-80
The MVC pattern facilitates the separation of concerns when developing interactive graphical applications. The logic and state of the application, how users interact with the application, and how application state is presented to the user are handled by separate elements of the MVC triad. Smalltalk-80 uses the MVC metaphor to provide built-in support for interactive application development. The idea was to provide a set of built-in user interface widgets such as buttons, menus and lists that can be plugged into a GUI application. To use these built-in UI widgets effectively, the application had to be built in accordance with the MVC metaphor. Let’s take a look at the conceptual diagram of a Smalltalk-80 MVC app.
Conceptual diagram of MVC in Smalltalk-80 (from Krasner & Pope)
All objects in Smalltalk communicate with each other via messages. Think of messages as a way to invoke methods in an object.
At first glance, the MVC conceptual diagram seemed a little strange. The multitude of arrows indicated more acquaintances than I’m used to seeing in an MVC diagram. Model-View and Controller-Model dependencies ran both ways. The second interesting aspect was that user input goes directly to the Controller. This is a significant change as we generally expect users to interact with UI widgets in the View. In Smalltalk-80, it looks like the raw keyboard and mouse input is fed directly to the Controller. Let’s take a quick look at how the MVC metaphor is supported in Smalltalk-80. Continue reading ‘Separated Presentation: The Classic Model-View-Controller Pattern’
Helper Class is Helped
I wanted to move on from the original Aid Game, at least as far as the movement was concerned; so I fully fixed it up. With the new set of rules from the
previous post of repairing the movement, I realized that if I didn’t generate fully operating movement states, we’d end up overly focusing on the wrong things. So, I set up a class (TimeMachine) to encapsulate the Timer object, and then the Mover class became the child of the TimeMachine using the different TimeMachine Timer properties. Because I instantiated a Timer object in each of the properties in the TimeMachine, I do not believe it is properly an Abstract class. However, like an Abstract class, it is not invoked directly, but rather through inheritance.
Playing the Game by the Rules: First Break the Rules
The nice thing about a State design pattern is that once the rules are established, you can build your algorithms and the different states invoke them according to the rules you’ve established. You can have a number of different algorithms within the State framework, and they should all work in accordance with the rules—no matter what the rules are or what algorithms you use to invoke them.
To see if the revised game follows the movement rules, try and break the rules. The main rule that you can attempt to break is the No reverse without stopping rule. So if you’re going right and you press the Left button, your helicopter should first stop and then you’d have to press the Left button a second time. Or you can reverse direction by pressing the Stop button and then press the opposite direction. Click the Play button to give it a whirl:
So go ahead and try to break the rules! If you can; then the design fails. If not, it succeeds. Once you’re finishing playing, download the latest code and see how the rules were applied.
Continue reading ‘New Aid Game: The Machine Moves!’
Fixing a State Design Pattern
In a recent post to illustrate the use of composition and delegation, I created a simple game using a State design Pattern—the Aid Game. A lot of people had lots of questions and suggestions for making it better and being one who thrives on improvement and change, I promised to have a post where we’d review it as a State design pattern and not a quick and dirty example of composition.
In this post I’d like to go over some key elements of a State design and to see if we can improve on the original Aid Game by better design of state classes. Also, I’m going to leave the final repairs up to you—I’ll provide some guidelines for improved states, and you can implement them. Also, I’ll provide a little helper class that is an example of continuous movement based on one from our book that Chandima used to illustrate MVC. (I simplified it from the original; so if you look at the MVC chapter—Chapter 12—, you’ll only see pieces of it.)
Why a State Design and What are the States?
To get started, we have to ask the same key question that we should ask for every design we do. Namely,
What varies?
In moving the helicopter around in the Aid Game, the main thing that varies is the state of flight. (Each of the different directions and a stopped state represents a variation in state.) Ergo, I selected the State Design Pattern.
In our simple State design, I used five different states:
- Stop
- Move Right
- Move Left
- Move Up
- Move Down
Next, I’ll add some rules that were not in the first version:
- Before reversing direction, you must first go to the Stop state.
- If a current state is called, it cannot invoke itself.
- Movement is continuous
Continue reading ‘Fixing the State Machine: Aid Game Repair’
Take This One to Work
After creating the post on the
acquaintance relationship between classes, I started thinking about the aggregate relationship and delegation. One of the best examples of delegation can be found in the State design patterns. All of the states are delegated to objects that handle each state. So I thought it’d be a good idea to create a little game that demonstrates both delegation and a state engine at work. Then, when I do the post on aggregation relations, I’ll have a simple reference point. This one is set up so that you can put it into your lunch bucket and take it to work. What’s more, it’s designed so that you can extend it into a more interesting game.
I decided that a good starting point would be to have a helicopter fly aid packages to different places on the screen. It would start at the airport and then fly the aid to different sprite objects representing groups of people in need. However, to get started, all I did was to set up five buttons to move the helicopter around the screen beginning at the airport. Figure 1 shows what the game looks like. (It is set up on an 800 by 600 display; so I had to cut off part of the right side to fit in this blog format.) The movement buttons are in the lower left portion of the screen.
Figure 1: State Pattern moves Helicopter Object
Click on the Play button to get an idea of how it works:
Continue reading ‘ActionScript 3.0 State Design Pattern: An Aid Game’
First off, Happy New Year and Happy New Decade to one and all. By the end of 2010, I hope I’m a better programmer than in 2009.
In order to be a better programmer I need to have a good resolution. I’d like to do something better this year while not abandoning good habits I’ve picked up over the time I’ve been trying to be a better programmer. (That actually makes sense even though a bit convoluted.)
So, now I’ve got to come up with a resolution. The one I want will do the following:
- It has to be one I can keep. If I aim too high, I may miss the mark and feel I’ve failed to keep a resolution. Aiming too low is just a waste of time.
- It has to be forgiving. That means that if I don’t keep it 100% of the time, it’s ok. Improvement, not perfection, is the goal. Improving habits eventually become part of my programming DNA, and it’s a step in the ongoing trek to be a better programmer than I was at this time last year.
So my New Year’s resolution is:
Improve nailing down relationships between classes in design patterns.
For example, when I look at a design pattern with an aggregate relationship, I want to be able to immediately imagine what the code looks like for that kind of relationship and how it differs from an acquaintance or some other relationship. Eventually, this will enable me to look at a design pattern in a UML and see the code-class relationships and how it might or might not solve a programming problem.
I’ve probably got a dozen other resolutions for becoming a better programmer, but they’re sort of always there nagging and whittling, nudging me in the right direction. (My wife has thousands of resolutions for me; none having a thing to do with programming!)
Ok, that’s it for me. How about you? What’s your New Year’s programming resolution? Put ‘em in our Comments, and at the end of the year we’ll see how we’ve done.
Bill Sanders
Recent Comments