Well, not exactly; I also had to take out the declarations of the controller and the model vars from all the subclasses.

I am really happy because I have learnt a lot reading that chapter. It has also been very useful for me. I have refactored a really clumsy little program of mine into a mvc pattern and it is now elegant and easy to modify/extend.

Thank you

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,

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder.

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

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

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

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.

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 :)

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

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?

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

…looking at the design patterns inside MVC should help you see what we mean by the term “pattern.”

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

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.