Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1] 2
Print
Author Topic: singletonless implimentation of puremvc  (Read 20628 times)
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« on: March 09, 2008, 03:26:26 »

not that I have anything against singletons, but I know a few people who just won't touch them.

So for their sakes, and as an intellectual exercise, I have removed them all.

practically speaking there is no difference for the user except two things.

you don't have to write a static singleton factory method on the extended facade, and in the extended facade's constructor, you need to send up a reference to itself in the super:

public function ApplicationFacade():void{
   super(this)
}

find source code here
www.revisual.co.uk/uploads/singletonlessPureMVC.zip
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #1 on: March 09, 2008, 03:33:00 »

Removing the singletons will theoretically allow many pureMVCed apps to exist side by side as there is no pollution of their Notification name namespace, as they all have there own MVC.

now I have only tested this an a single app, and it works fine.  It hasn't actually been tested with several apps running side by side (hence my use of the word theoretically)
Logged
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« Reply #2 on: March 09, 2008, 08:31:29 »

I've finished my singleton less version a few weeks ago as well. Made a demo as well. But couldn't post it because it was based on version 2.0 which wasn't released yet.
I knew I should have posted some explanation so that people knew it was coming.

It's good to see we both came to the same solution :)

The only differences:
  • What is this appFacade parameter used for? I just use this as the instance.
:
public function Facade( appFacade:IFacade ) {
instance = appFacade;
initializeFacade();
}
  • Instead of setFacade I use the following syntax, just personal preverence.
:
function set facade(facade:IFacade):void;
  • In the 2.0 version IMediator, IProxy, ICommand extend INotifier, so the casts when setting the facade become unnecessary.
I see the version2.0 unit tests are online, so I'll try to test my version as soon as possible.
« Last Edit: March 09, 2008, 08:42:55 by theFlashWizard » Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #3 on: March 09, 2008, 10:32:30 »

cool.

the appFacade parameter is a referance to the extended Facade (ie the sub class specific for each application). So when you initialise the extended facade, it passes a referance of its self up to the super constructor (the Facade). So it is this instance which is passed around the Frame work, not the abstract Facade. 

but now I see that maybe it isn't necessary, and that a simple 'this' would suffice.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: March 09, 2008, 12:10:39 »

Fleecie,

>>not that I have anything against singletons, but I know a few people who just won't touch them.
And I hear the Amish don't use telephones.  ;D

Seriously, it is an in interesting idea that's been batted around a bit here. I appreciate the effort, on both of your parts to explore the idea. The problem of running multiple Cores (for Flex Modules or Flash based apps or a mix), is a big one and now it has been explored from all angles.

One approach was to register and unregister all the commands, Mediators and Proxies for a Module when its loaded. It involved a lot of coordination to keep track of what to load when and still had namespace issues. That is notification constants in two different apps could interfere with each other since they were registered into the same Core.

Then there's the Singleton approach that says, the problem with running multiple cores is that the singletons keep you from creating more than one blasted instance! What a pain. If they were like regular classes there'd be no problem... That is except that in any but the most trivial parent-child case, you will end up writing special actors to manage the separate cores.

There is a reason for the use of Singletons in PureMVC as there is for every pattern in the framework. The reason, as described in the Gang of Four book,  is to absolutely insure that an actor cannot be instantiated more than once.

The classic retort to this is just don't instantiate more than once, but it is often the case that that best practices, or sometimes even common sense isn't followed by 'other' developers. This can be due to lack of time, discipline, familiarity with the tools at hand, or any number of pressures.

For instance, I came across this developer's sad lament: http://board.flashkit.com/board/showthread.php?t=760317

Dropped into a project late, the guy finds himself in an app where apparently all the rules have been broken. He's trying to figure out not only the best way to use the framework but also how to untie this other person's knot at the same time.

So imagine this is not code for 'Yet Another Flikr Gallery - Beta' but, oh, lets say a pacemaker. And the existing app you're supposed to figure out has this nasty problem of sometimes instantiating more than one clock, causing the patient to dance like a chicken briefly before collapsing of heart failure. But it only happens every now and then.

The point is there are times when you want your software to create only one instance of something no matter what and that's when you reach for the Singleton pattern.

However, we do want multiple MVC Cores to be able to reside peacefully and interact. To communicate with each other even, without namespace collision or extra overhead to manage the separate Cores.

And to this end a new version of PureMVC - 'MultiCore', has been created using Multitons rather than Singletons for the Core actors. The difference is that rather than holding a single instance, each actor holds a hash of instances, each with a name, in the same way that Mediators and Proxies are cached.

This achieves the same end, but still ensures that your app cannot instantiate a given Core more than once. It works with Flex Modules and but will work with Flash movies as well. The management of all the instances is handled by the actors themselves as it always has been, you merely pass a unique key to the getInstance method.

The really nice thing about it is that all the same assumptions about the framework actors remain true, known best practices still apply and you now have implicit support for Modular development.

-=Cliff>
Logged
trilec
Sr. Member
****
Posts: 52



View Profile WWW Email
« Reply #5 on: March 09, 2008, 12:29:07 »

Hi All,
would you mind elaborating on why the need for multi MVC's (multiCore)   or the circumstance this would become an issue?
or even perhaps under what circumstance is a split considered?


thanks
c


 
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #6 on: March 09, 2008, 12:35:11 »

Consider an application like Netvibes. You load lots of widgets at runtime, based on user config. Each widget can be its own complete self contained PureMVC app. You don't want to write one monolithic app with all the functionality in it. Especially if you want to open a third party widget development platform.

-=Cliff>
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #7 on: March 10, 2008, 02:50:12 »

will the multicore version be in pureMVC 2?

I'll be interested to take a peak when it comes out
Logged
trilec
Sr. Member
****
Posts: 52



View Profile WWW Email
« Reply #8 on: March 10, 2008, 05:20:56 »

Consider an application like Netvibes. You load lots of widgets at runtime, based on user config.

hi again,
just to clarify, when there is no interaction between other applications a split should be considered?.  it seems this area could become gray went a little interaction may be called for.
ie. in the case off Netvibes , a widgets location or perhaps what widget to load etc.

On a side note:
It feels to me much confusion lies in the what, where, why. with regards to pureMVC. looking into the code definitely helps but as a newbie it would be nice to see just the outline of what went where why, even perhaps if they where theoretical and there was no source code.
eg.
FOO COMPANY:
overview:
basically a page allowing a login process, user details and their account details, Singleton method used.
models:
   user -   Basic user details, ID password
   account -  basic account details, name address

Views:
   login UI
   user details
   basic account details
   advanced account details

controller:
etc.
Other stuff Im unsure about: ...lol

This of course is a very simple outline and majority of websites would be far more complex with transition management, multiMVC's, deep linking or state machines.
I'm not sure if you would find this helpful to have in the Docs section
I'm willing to work through the current demo source code and extrapolate into some form of overview but it would also be nice if others with far more experience upon completing their project would consider this form of breakdown.

Anyway just a thought.
Many thanks for the time you've invested in pureMVC
 
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #9 on: March 10, 2008, 07:56:16 »

>>When there is no interaction between other applications a split should be considered?. 

Its entirely possible that you still might modularize something even if it doesn't communicate with the other cores in an app. Just to keep from having to load it to start. Perhaps its functionality that's big and talks to a lot of services at startup and you want to only load it when you need it.

As for tutorials or docs we sure can use 'em. There'll be more in time, but anything you can do now would be a start!

-=Cliff>
Logged
trilec
Sr. Member
****
Posts: 52



View Profile WWW Email
« Reply #10 on: March 10, 2008, 04:08:18 »

Its entirely possible that you still might modularize something even if it doesn't communicate with the other cores in an app
I think you ment "even though it does communicate".?

So you are referring to load-balancing using multi-cores? har har, yet another discussion point and design decision. :-)
I started a design for an interesting social network site before finding pureMVC.
But as with any large application trying to not overengineer and making the correct design choices before coding will make life easier down the road.

regards
Curt

 
Logged
joe
Newbie
*
Posts: 5


View Profile Email
« Reply #11 on: March 10, 2008, 09:37:59 »

I hate to be nit-picky but I did want to point out that a few of the authors of the GoF book have stated numerous times that the singleton pattern is only used correctly when it fits both of the qualifying reasons.  The first being that there should only ever be a single instance, and secondly that the actual actor is needed globally and you can expect any class to want to call on it.  I forget which author it was, but one of them has stated that it is very close to an anti-pattern (and is when not used with both rules) and wished it was not included in the book.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #12 on: March 11, 2008, 06:21:09 »

Ok. And how does the use of singletons in PureMVC violate this?

-=Cliff> 
Logged
joe
Newbie
*
Posts: 5


View Profile Email
« Reply #13 on: March 11, 2008, 06:59:27 »

Cliff,

Actually PureMVC really doesn't violate it to be honest, I was just pointing out one of the reasons people do hate singletons.  While it is true that you never need to globally access the Model/View/Controller classes, you really are working with the actual objects at a global level (as the Facade is doing this).  So in my opinion it doesn't make a difference whether they are singleton or not, but to a pattern die-hard they would likely point out that the MVC classes do not need global access (as the Facade provides this) and therefore should not be singletons.

Again I'm using PureMVC for quite a large project and don't have any gripes with it, just pointing out what has been said about the use of singletons and why some people my opt not to use many of them.

PS. Great job with 2.0, I love the onRegister/Remove on mediators and the naming of them.

Ok. And how does the use of singletons in PureMVC violate this?

-=Cliff> 
Logged
theFlashWizard
Jr. Member
**
Posts: 13


View Profile Email
« Reply #14 on: March 12, 2008, 06:20:55 »

To explain again why singleton is bad for PureMVC:
- Every "module" (separate pureMVC) always exist. So when you have you widget application, a widget never get deleted after use. Waste of disk space.
- It's just as easy to do
facade = ApplicationFacade.getInstance("uniquename");
then is is to do:
facade = new ApplicationFacade();

Like I sad in this topic:
http://forums.puremvc.org/index.php?topic=235.0

Interesting literature:
http://www.ibm.com/developerworks/webservices/library/co-single.html
http://steve.yegge.googlepages.com/singleton-considered-stupid

Ok. And how does the use of singletons in PureMVC violate this?
A Singleton always exists, which you don't want if you have multiple PureMVC's parts which you can close and open.
The global access isn't necessary because you can easily pas a reference trough the framework.



I just got my Modular PureMVC version trough the unittests. So I'll be posting it soon.
To start of the right way, because this version is different to the original, there is no official support for it.
I will post a demo, and I updated all the comments in the classes, but that's it.
Logged
Pages: [1] 2
Print