Deciding on a Design Pattern
One of the most difficult questions to answer is also the most often asked: How do you know what design pattern to use? My standard response to that query is,
Ask, “What varies?”
Of course, it seems that everything varies just when you need a nice clear answer to that question. The Gang of Four provides a list of design patterns and what varies in each pattern—such as states of an object, an algorithm, responsibilities of an object without subclassing and so on. However, determining the nature of the variation can be as difficult as deciding the design pattern to use as looking at class diagrams. (Download the AIR version of the Variation Table—also known as The Magic Table.)
Go To The Original Source
Chapter 1 in the Gang of Four’s book is the gateway to design pattern knowledge. I must have re-read it 50 times. Further, every time I re-read it, I get something new. You can download Chapter 1 of Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—just click the download button to bring up the PDF file and then save it:
Find the section, How to Select a Design Pattern and read it. Even if you don’t get it all the first time through, you’ll have a better idea of design pattern selection. Now you’re all set to continue with the rest of this post. Read on!
Continue reading ‘How to Pick the Right Design Pattern: Fortune Favors the Prepared Mind’
I’ve been working on a project with Adobe Catalyst, and if I didn’t do something for a Design Pattern tour now, it would be put off until I don’t know when. So I put together a non-design pattern application incorporating video and code snippets from the Aid Game. I simply have not had time (given the work I’m doing with Catalyst) to put together a more generic design pattern “thrill ride” that I planned; so while I’m working with Catalyst, I thought I’d might as well do something with design patterns and came up with this more mild tour instead of my planned thrill ride. Figure 1 shows what it looks like:
Figure 1: Tour through State Design Pattern
As you can see it’s pretty simple—sort of a PowerPoint chat. (Nowhere near as flexible as the one created with the Memento pattern.) So, if you’re interested in a mild tour, click the Play button and hop on:
By the way, the Catalyst project has made me far more aware of Flash Builder/Flex code. It uses Flex in its engine. If you’re interested in Catalyst, you can download the Beta at Adobe Labs. I tried importing programs (SWF files) made with design patterns, and it works great. About the only thing I didn’t do with this tour is to put the videos on Flash Media Server—sorry. I was in a hurry and wasn’t sure how to link up FMS to Catalyst. I could have written the code in Flash/Flex and created an SWF file to import into Catalyst, and that works fine, but I’m pretty pressed for time on this project.
As always, your comments and valuable feedback is encouraged. I’ll be back working on this blog as soon as I’m finished with the Catalyst project. Besides, Chandima has been writing knock-out posts to keep you interested!
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’
Bill Sanders
Recent Comments