My initial idea of having a “thrill ride” through a design pattern to help reveal its operation is turning out to be awkward in more ways than I envisioned. The initial tour is going to be through a State Design Pattern; so naturally I set it up using a State pattern. It wasn’t too long before I realized that it would be difficult to visit all of the participants without adding new states that would show visiting the Context and State interface. In other words, I needed VisitContext and VisitState state classes.
After some fumbling, I saw that much of the important work is done by the Client. It actually works like a composer, especially since the State design is a beautiful example of both composition and delegation. Each participant had some responsibility in the process that I wanted to reveal in the sequence in which it occurs. With the State design, this is especially challenging because the context changes with each state. So how does one go about making a tour of such a process?
What Varies?
Then it occurred to me that were I to spend time on setting up a tour of the State design pattern, why not create a reusable application that I could use on any pattern I wanted? Of course this brought me back to the most basic question of design pattern development—what varies? In other words what varies in a tour of a pattern? So I whipped out my Magic Table to look at the possible variations in a design pattern. Well, I knew that the patterns were going to vary, but what does that look like in the Magic Table? Here were some that stood out:
I’ll get to the decisions involved in deciding on the best design pattern for making my thrill ride through different design patterns in a bit, but first, I wanted to consider the initial animations, graphics and design. The embedded SWF shows what I have in mind. The “control panel” is made up of buttons representing the different states (The animation just goes from the Client to the Context but it gives an idea of the animation I’m considering. It only goes to one state and then this page has to be reloaded to start over.)
[swfobj src="http://www.as3dp.com/wp-content/uploads/2010/02/ClientTest4.swf" align="none" allowfullscreen="true"]
Read more…
Creates Relationship
One of the least discussed relations in Design Patterns is where one participant
creates an instance of another. Basically, the pattern calls for one class to instantiate another class. This relationship is indicated by a
broken line with an arrowhead pointing to the class that has been instantiated. (The Participant Relations diagram above shows
Class C instantiating (creates)
Class F with the red broken line and arrow.) The
creates relationship is found in only five design patterns:
This post examines how design patterns incorporating a creates relationship uses that relationship to make a loosely structured design to complete one or more kinds of tasks.
Read more…
We got a request for a post on the Model-View-Presenter (MVP) pattern sometime back. As always, I did some digging and realized that there were very few examples of MVP that described its implementation well enough for someone to understand the subtleties of the pattern.
Subtle differences
Subtleties are the key issue with implementing presentation patterns. When I say subtleties, I mean much more that the how, of the implementation, but the why as well. Why would you want to implement an MVP architecture as opposed to an MVC? What are the potential advantages and disadvantages? I ended up comparing and contrasting GUI architectures such as MVP, MVC, Presentation Model, Supervising Controller and Passive View. When I found an example of an MVP, I found myself coming back to Martin Fowler’s work on Enterprise Application Architectures to iron out my doubts on the implementation. Fowler has not only done an excellent job of describing the differences between presentation patterns, but ties in the history and evolution of GUIs as well.
Separation of concerns
Separated presentation is a key theme in all GUI architectures. Much of the discussion on GUIs concentrate on separating the presentation layer elements, such as presentation logic and user-interface widgets, from the rest of the application. This separation is useful in that dependencies between the presentation layer and the rest of the application can be managed, allowing more effective development and testing. This is essential in Flash development because we deal with very rich GUIs that contain many complex UI widgets. Architecting the application to allow distributed modular development of the presentation layer can go a long way in streamlining the development workflow.
Walk-the-walk
This is the introductory post on a series of upcoming posts on presentation patterns where I take a mindful walk on the path carved out by Martin Fowler in his chapter on GUI Architectures. Mindful in the sense that I’m bringing a Flash and ActionScript mindset to the journey. This path has been traveled before, by Paul Williams. For contrast, I’ll be using the weather maps sample application from Chapter 12 in our book to provide a fresh set of examples on the following presentation patterns.
Inheritance Relations
An open triangle on a line from a child class to the parent class indicates the
inheritance symbol in Design Pattern class diagrams. In the Participant Relations diagram above, you can see symbols for both single and multiple inheritance in red. Inheritance in design patterns is so common, pointing out which designs
do not use inheritance is easier than listing all of the ones that do. Those pattens that have
no inheritance in their design include:
So when thinking about inheritance, you can begin by thinking design patterns because most include some kind of inheritance in the relations between pattern participants.
But I thought they said…
You’re probably thinking that a key principle for design patterns is to favor object composition over class inheritance, and here we find that the Gang of Four is using inheritance in all but three of their design patterns. What’s up with that?
Read more…
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.
Read more…
Bill Sanders
Recent Comments