Truckin' thru MVC
Looking at the design patterns inside MVC should help you see what we mean by the term “pattern.”
The phrase, the design patterns inside MVC is where the trolly may have jumped the tracks.
I believe that the design pattens that GoF are talking about in reference to the MVC are actually classes that have certain design pattern features found in patterns such as Strategy, Observer and Composite, but they are not referring to the entire pattern. Many design patterns have classes or operations that reflect the entire design pattern. For example, the Template Method pattern has a function (a method) that is a called a template method. So you can have just a single method that describes an entire pattern. Likewise the Stratey pattern contains an interface called strategy, the Observer has an interface known as, observer and the Composite pattern has a concrete class named composite. What makes the MVC valuable is that it contains elements of these other patterns to aid in understanding design patterns in programming. In and of itself, it is good for certain applications, but only to a limited extent. The point is that GoF use MVC to,
LLUSTRATE how classes and objects work interdependently to accomplish a task that can be reused and easily changed.
Another source of possible confusion is the figure on page 5. The different graphs and charts are labeled views and the percentages at the bottom are labeled model. It is used to explain the role of the model and view in the MVC. So naturally, in situations where you have multiple views for a single or multiple data sources, you think of MVC. However, that exact same figure is found on page 293 in the chapter on the Observer pattern, but the charts and graphs are labeled observers and the data source, subject. The lines between the different parts are identical in both illustrations—including the labels on the lines. On pages 317-329 of our book, you’ll find where we used the charts and tables to show how the Observer design pattern can be usefully adopted to generate different views from a single data source. In the context of the GoF book, the illustration on page 5 is to show how different classes interact and is a useful tool for an illustration—and really nothing more. Figure 1 shows how users changed a demonstration into something it was not intended to be:
Figure 1: What the MVC is (left) and how it has been used (right).
Often, critics beat up the MVC for not being a one-man band when all it was meant to do was to play the cornet.
The True Value of the MVC
Because the MVC was the last pattern I spent any amount of time with, I looked at it with a different perspective. I knew of several different patterns that could be used to accomplish what the MVC does, and so I didn’t consider the MVC as the be-all and end-all of design patterns. It is most valuable when used as GoF intended—a leaning tool. After working through an example, I found the circular communication between the Model, View and Controller very educational. As a device for learning how event dispatching works, I can think of no better. Knowing how classes communicate is essential to understanding design patterns, and for that, the MVC does an excellent job. I truly believe that was the intention of GoF and nothing more. They say as much.
After going over Chapter 12, in our book (one that Chandima did), I learned far more about inter-class communication than I believed was left to learn. (By the way, if you found this series useful, you’re going to be amazed by what Chandima has done with MVC in Chapter 12, both in ways of MVC use and as an explanatory tool for inter-class communication.) My own conclusion is that everyone interested in design patterns needs to spend some time with the MVC to better understand design patterns in general. However, I see it as a fairly limited tool that does a very good job of just a few things and other design patterns are better suited for most tasks. At the same time, I do not think it is the villain some have portrayed it to be, and it has often been criticized for not being an apple because it is an orange. By the same token, I don’t think it’s the Swiss Army Knife of design patterns. It is what is always has been in the context of design patterns—an illustration of interacting objects.
The Truckin’ Through ActionScript 3.0 MVC: Part V—Purpose and Use by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Related posts:
Bill Sanders
Hello Bill,
The Command Pattern seems to be often used to make interfaces, as you show it with a menu (invoker) in your book.
I’m wondering if it is a complete and efficient alternative to the MVC or if they can be used together (the Command Pattern in the MVC) ?
Patrick
Hi Patrick,
As you know, the term interfaces has many different meanings in OOP. If you’re referring to user interfaces (UIs), then the Command pattern does a nice job. Whether you’d want to use it with the MVC or not depends on what you want to use it for. Take a look at the AIR application that shows answers the question of which DP to use depending on what varies. Remember, only use a pattern that fits your needs—not because it’s handy.
Kindest regards,
Bill
Hi Bill,
Thank you. Effectively I was referring to UIs. So MVC and Command Pattern can work together. The better is if I make a try… maybe the Command pattern could take the place of the controller ?…
Just another question:
There is one thing that seems to help a lot with the MV(C) is for making clones. For example if you click on a sprite and if all the clones of this sprite move the same way at the same time.
Exactly it’s the concept of separing the model and the view witch is very important to accomplish that (composite and strategy are not very important in this case).
You say that you knew of several different patterns that could be used to accomplish what the MVC does, is there one witch could help too to make clones ?
I forgot to say that as usual your article is very interesting.
Patrick
Hi Patrick,
Usually when you think of making clones, the Flyweight comes to mind. You will find an extended example of the Flyweight with clonning here. If you do go ahead and clone using the Flyweight pattern, I’d like to hear of your experiences with it.
Kindest regards,
Bill
Thank you ! I will look at that and tell you.
I believe the example you presented in part 4 is possibly the worst example I could think of.
It’s not a very big example, but it’s big enough to have a gaping error.
The views.
The whole point of MVC is to prevent you from rewriting code and using copy&paste. Why on earth would you want to duplicate the slider code? The slider code should be, by all means, a separate view component.
Second is the proxy, or model issue. The model is there to do business logic. In this example we have no business logic, and so no need for a model. One very important thing in programming is to know when NOT to make something pretty, well-coded and extendable. You need to have realistic expectations and expose, in code, only the things that need to be exposed.
This example would be teaching people bad habits, meaning that an enclosed piece of data that interacts with only one view component should be externalized (that is, instead of being declared as a private var in the mediator, it should have it’s own mediator) – so someone would, for example, create a separate proxy to handle the position of a visual decorative element that moves to the position of the last menu item you hovered your mouse upon (not clicked, not selected, just hovered). Baseline rule: do a model for the data if it’s going to be accessed by more than one MVC component. Unless you want to get yourself fired.
And I can’t see that kind of requirement here. How could that be fixed? Add some business logic, like calculating the degrees based on declination and position. Then there would be a real need for a proxy, as that kind of code doesn’t belong in a mediator. Then separate the view components into a slider and compass.
And while I’m at it, loose coupling. Even though MVC at it’s core is about separating the components and making it as free of dependencies as possible, that’s not the case here.
Next time try demonstrating all this using pureMVC. It’s a strict framework, if a bit uptight. Or robotlegs, which is kind of like pureMVC made right and made to get things done.
Hi archont,
I guess you wanted a different ending to the truck through MVC… First of all, thanks for expressing yourself so clearly. Second, I think you missed the point I was making about MVC. While to some (yourself perhaps), the MVC is a generalized framework, to me it is nothing more than a vehicle for looking at design patterns. My focus was on looking at the interaction between the Model, View and Controller; not to provide a prototype for using it beyond what I believe its primary purpose is in the Gang of Four’s book. The Model is a data source with input from a UI. As you suggest, using the Model with business logic—especially the kind you provide as a requirement—is certainly better than what I had. (In fact I really like your idea!) The View is for setting objects on the stage, and the Controller for handling user interaction. Those three elements can be used for a myriad of tasks.
However, that’s not what I was trying to do. I was showing the interaction between the objects in the MVC. That, I believe, is what Gamma, Helm, Johnson, and Vlissides were doing as well. The example was short and focused on those elements.
What you and others have done with the MVC is beyond the purpose to help understand the idea of patterns. As GoF say, the purpose of the MVC in their book is
The pureMVC is clearly way beyond the MVC, and Chandima has made that very clear in his posts on the subject. So, I’m not about to attempt to improve on the MVC or pureMVC. That was never my intention, and I said so.
What I invite you to do is to take the compass example and fix it as an MVC (not a pureMVC) to demonstrate how it would better show the interaction between classes. We’d be glad to post it.
Kindest regards,
Bill
You’re right, pureMVC isn’t pure MVC. It’s actually more than just MVC, my mistake. Then again, I blame it on the “pure” being misleading, so there! ;)
I just might redo your example, although I’ll have to try hard not to reimplement a micro-sized puremvc in it – old habits die hard. While there won’t be any singletons, the view will be composed of components (to avoid using puremvc’s phrase “mediators”) and all information will be passed using flash’s events. I’ll try to do a classic controller instead of commands, but I’ll have to think for a while on how to display the controller’s functionality in a simple yet useful way.
Then again loose coupling, while a great idea, isn’t exactly in the formal description of what MVC is, and while doing the example I fing the most important thing is to show the core of the idea and when it can come in useful, and where it should be avoided. I could tighten the coupling somewhat by using interfaces, while still being able to swap components ad hoc.
Which do you think would be better?
Hi again Archont,
I’m a very big advocate of loose coupling because with it it’s easier to update and change; the purpose of design patterns. However, I’ll not quibble with any idea you have, and if you want to tighten the coupling go ahead. I’m very glad you’ll not include Singletons—I’ve made my views on the Singleton quite clear.
Our blog welcomes ideas and discourse; so do it any way you see fit, and we’ll show it off.
Take care,
Bill
Hi,
I finnaly made a try with the Command Pattern and a sort of MVC and I find it’s interesting.
Simply, the Command Pattern changes the Model data and activates its functions, then the Model dispatches the usual “change” events that update the View.
So it’s the Model View Command :)
Hi Patrick,
It is not uncommon to implement the controller in the MVC architecture as a command pattern. In fact many AS3/Flex frameworks such as PureMVC and Cairngorm do this.
Hi Chandima,
Thank you for the precision !, happy if it is an usual pratice, I will now use it with less wondering if I do something wrong.
Patrick
hi, i was reading your book, while it has good learning resources, the book by itself is very bad, a lot of words to explain simple things, a lot of paragraphs to explain something that can be told in a few lines. is more an egocentric monologe than a real purpose of teaching.
if you people want to see an exelent book, maybe the best, about design patterns, go for: “desing patters for dummies” is java oriented, but is by far, the best book about this topic
h t t p://www.amazon.com/Design-Patterns-Dummies-Computer-Tech/dp/0471798541
Hi there Dyei Nightmare,
Well, it’s fine if you want to promote a book on design patterns you like. However, we don’t feel that you were very fair to us in claiming that we were verbose in explaining design patterns for ActionScript 3.0. We are not using a lot of words to explain “simple things” or using several lines that “can be told in a few lines.” (Egocentric monologe? Outch! You hurt our feelings by such unkind words.)
The very first sentence in the Gang of Four’s book is,
So, forget about explaining simple things. We’re dealing with hard things and trying to do so adequately. Chandima and I had our egos stomped on in preparing our book (and our blog) because we both realized that we were dealing with some very smart folks.
As always, we’re interested in good books on design patterns and welcome one and all. The main book that we rely on is Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides. However, we have also found that the Freeman’s book, Head First Design Patterns is also excellent. Both take very different approaches and use different languages; Softtalk-80 and Java, respectively. Our goal in writing our book (and this blog) is to address the issues of creating design patterns using ActionScript 3.0 doing our best to combine principles of programming in OOP and the structures in design patterns.
We certainly do not compete with (or malign) Design Patterns for Dummies. We’re simply dealing with smarties and so our approach is a bit different.
Kindest regards,
Bill