Tying MVC together with AS3

[NickZA]

Hi

I'm building the framework of a game at the moment and am using the MVC approach. The State DP is integrated into this structure to define gamestates. Also, there are a numerous singletons in the class structure including 2 discrete data models, the logger and the console.

While broadcasting events out from these objects enables loose coupling, the array of controllers (states) need direct access to the data models. For MVC, this is typical.

So, my problem is getting a data model reference out to the various states that perform the game logic. My problem is essentially twofold:

1. I want to maintain loose coupling to keep my codebase extensible.
2. I want to use the singleton pattern for singleton objects, so that there is a single, accessible point of access to the model for all objects (such as states) to reference each singleton. (I am not worried about enforcing single instantiation, only about referencing a single instance.)
3. I want to give my controller objects an implicit way of referencing the data models (preferably in keeping with point 1), eg. I want to avoid passing arguments, using globals, etc.


When the model is created, I can do one of the following to get it's reference to the individual states:

--Create the singleton objects and have any states call a static getInstance method of the Singleton superclass -- except static functions aren't inherited. This is my preferred route but I can't get it working, see here:
http://www.kirupa.com/forum/showthre...223798&page=35
(In spite of my response there, I later realised I was no better off with the given "solution".)

--Create semi-singleton objects (no instantiation enforcement, but still have non-static getInstance() methods referencing a static instance variable). I like this option, but can anyone clarify why Singleton's need a static getInstance() method? Am I safe in dropping it?

--Every time a new state is called, pass the data model ref into the new state, from either the old state or the StateManager (which holds a permanent reference to it), as a parameter. I don't like this: it just seems ridiculous to be passing params when in reality every state should, by it's very nature, be able to access the model. In fact, the model(s) should be able to be accessed by pretty much any object in my program that wishes to access it.

--Don't enforce singleton behaviour, instead store the ref in global variable. I smell rubbish...!


Long post, I know. Any ideas?

-Nick

[creynders]

I'll answer you questions in a different, but probably more understandable order:

Create semi-singleton objects (no instantiation enforcement, but still have non-static getInstance() methods referencing a static instance variable). I like this option, but can anyone clarify why Singleton's need a static getInstance() method? Am I safe in dropping it?

You need some kind of static access point. Whether it's a property or method is irrelevant, but it will have to be static. Why? Because the whole point of the singleton class is to leave the responsibility of instantiation out of the hands of the user of the class. If you create a non-static method ( aka a INSTANCE method ) you already need an instance to ... access the instance. As you can see that's a bit like the chicken and the egg.

Create the singleton objects and have any states call a static getInstance method of the Singleton superclass -- except static functions aren't inherited. This is my preferred route but I can't get it working

And you won't get it working. There's a reason why you haven't found a extendable singleton class online, because it's not possible. For each singleton class you'll have to write a getInstance method and and a instance property, there's no escaping that.
For a singleton class you need a static property which stores the single instance of the class and a static method to access that static property. Since static functions and variables aren't a part of the inheritance chain, what you're trying to do is impossible.

So, the real solution is:
drop the idea of a super singleton class.
Implement the singleton pattern in each class that needs it.
Let the various states access the singletons directly.

[NickZA]

Hi Creynders

Remember receiving useful help from you in the past, good to see you again.

I didn't think that there was a way around it and since writing this had started to come around to your way of thinking -- thanks for the shove, however . I think it was needed.

As you say, there are a ton of different methods for implementing faux singletons in AS3, and not one of them can satisfy all criteria of a true singleton, obviously.

Thanks again.

-Nick

[swivelmaster]

Why not use an MVC framework that has already been built for you?

We've been using PureMVC at my company since before I started working here and it solves all of those problems.

[creynders]

Yep, puremvc is magnificent. The learning curve might be a bit steep if you're not familiar with mvc, but it's worth the trouble. And the most excellent part of the framework is the huge amount of documentation, tutorials and info found in the forums.

[swivelmaster]

I'd actually say the documentation for PureMVC both hurts and helps. When I started here, my boss explained a little bit about MVC in general, a bit about PureMVC, then showed me their incredibly complicated chart which demonstrates the structure.

My eyes glazed over.

Then he said, "Yeah this chart isn't very good. Ignore this. I'll just show you what we're doing with it."

Unfortunately, PureMVC doesn't solve *every* question about design, so we've been able to code some pretty rickety stuff that started out as a quick fix and then sat around for months before it was cleaned up. This is also a byproduct of just how flexible Flex and AS3 are and the fact that it's possible to put business logic in your view components (generally a bad thing to do) in Script tags. So be careful!

[NickZA]

Hah, what a coincidence.

I just did a search on "as3 loose coupling" in google, and this was my first result. Is it any coincidence that I happen to be working on MVC once again, and retrying it from a new angle?

As it happens, I dropped the idea of using singletons a while back. I just read this article about why not to use them, and to me all these arguments make sense:

http://www.as3dp.com/2008/11/26/we-d...0-programming/

ANYHOW, to my question....

I am still trying to "tie MVC together with as3", as the topic goes. I've built a functioning model and view (or parts of the overall, anyway). "Functioning" doesn't mean "extensible" though, and so here comes my (new) question on this topic.

I have a package net.blah.model containing 2 classes:

MapData (the actual data model)
MapGenerator (creates/affects the model, but is really sort of a controller)

I also have other packages net.blah.view and net.blah.controller.

MapData has methods which make changes to it's own data. These are specified as internal and so they can be called by MapGenerator, which needs to affect the model. That is why I encapsulated them in the same package. At first this seemed fine, but if I'd thought this througha little better I would have realised... ...

MapGenerator isn't the only thing that will be able to affect the map. During the game, for example, you can tunnel through walls (think Roguelikes). This means the MapData model will be affected by game controller logic directly (note, my initial distinction was that the MapGenerator is not "in-game" but rather "pre-game" logic, so this didn't matter much). So now I realise I will have to change the MapData model on the fly -- meaning that my current "tight-coupling of classes within the same package" method no longer works. The controller classes for in-game will be in the net.blah.controller package and thus will not have access to internal methods of MapData.

This brings me to my point. I have often considered setting up a competely event-based application framework, and in this case I wonder if it is not the only real solution in the absence of something like friend classes which C++ has. Even if AS3 had friends, this would promote tight-coupling.

Is interaction between the Model, View and Controller in AS3 best implemented using event broadcast between the members of the triad? For that matter, is this a good assumption when using other languages such as Java? And does this seem to you to be the best solution for my game MVC, as it presently does to me? Are there any pitfalls to be aware of?

Many thanks to anyone who reads allthe way through this.

Regards,

-Nick

[creynders]

Originally Posted by NickZA

Is interaction between the Model, View and Controller in AS3 best implemented using event broadcast between the members of the triad? For that matter, is this a good assumption when using other languages such as Java? And does this seem to you to be the best solution for my game MVC, as it presently does to me? Are there any pitfalls to be aware of?

I'd say yes and no. Since communication through events promotes loose coupling. The dispatcher doesn't need to be aware of what exactly is listening (or even if anything is listening) and the listeners don't need to care where they get the events from.
So the model should signal updates to it's data through events, but I don't think it should distribute that data through events. The controller and view should listen to the updates and then use a direct reference to the model (or a reference to a common interface) to access the updated data.

And then about your "internal" model problem: what you could do (if you don't want to refactor your model) is create a proxy for the model, which is public and then access the model through the proxy. In the proxy class you can use the flash.utils.Proxy class to pass all property and method calls to the model and back.

[NickZA]

Hi Creynders, thanks for stopping by.

Originally Posted by creynders

The controller and view should listen to the updates and then use a direct reference to the model (or a reference to a common interface) to access the updated data.

Just so I know I'm on the right track here, the direct reference would really just be the event.target, wouldn't it? (and as you say, as specific class or a general interface) Particularly in the absence of static refs / singletons.

Originally Posted by creynders

And then about your "internal" model problem: what you could do (if you don't want to refactor your model) is create a proxy for the model, which is public and then access the model through the proxy. In the proxy class you can use the flash.utils.Proxy class to pass all property and method calls to the model and back.

I certainly do want to refactor my model in as correct a fashion as possible at this stage. But I gues this is a plan B. From what I understand (having only just looked into the Proxy class for the first time now that you mention it) it doesn't seem a very "pure" solution.

[Groady]

@NickZA

Regarding your internal-model issue I agree with creynders in either using a proxy OR refactoring your model by including an entry method visible to your game controlers. You would either simply change your interal methods to public or create a new method which will interface with the relevant existing methods. It makes sense (to me) that all traffic going in and out of your model package will go through the MapData model.

On a side note, you say you've abandoned the Singleton design pattern. How are your view's and controllers getting their reference to the model? Through their constructors? Just curious.