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]
Print
Author Topic: Tell me why this is a bad idea: facades return their own instance sans key  (Read 3997 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« on: March 07, 2010, 07:00:49 »

Ok, I am trying to put together my first MultiCore application.  But there's one pill that I am having a hard time swallowing:

In each core's ApplicationFacade class so far I've seen:

:
public static function getInstance( key:String ) : ApplicationFacade
        {
            if ( instanceMap[ key ] == null ) instanceMap[ key ]  = new ApplicationFacade( key );
            return instanceMap[ key ] as ApplicationFacade;
        }

But these ApplicationFacades are package/core specific.  So... assuming only one instance of one core is ever around at one time, why not just return that instance?  Keep the key internal...

:
public static function getInstance() : shell.ApplicationFacade
        {
            if ( instanceMap[SHELL_KEY] == null ) {
                instanceMap[SHELL_KEY]  = new shell.ApplicationFacade();//calls super() with SHELL_KEY
            }
            return instanceMap[SHELL_KEY] as shell.ApplicationFacade;
        }

...and so forth with each core's ApplicationFacade?
Again, I know this won't work with an application like PipeWorks Prattler demo, but in my case I can honestly treat each core sub-application as a singleton.  Having to manage the core applications' facade keys outside their specific Facade class seems overly complex. 

But then, having the multiton in the first place seems irrelevant once I start to go down this path.  So what is wrong with this approach?  I feel like I am totally missing the big picture here...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 08, 2010, 03:54:28 »

Sure, you can define it on the class instead of passing it in, but having multiple instances of the same module alive is ruled out.

I know this won't work with an application like PipeWorks Prattler demo, but in my case I can honestly treat each core sub-application as a singleton.  

Precisely. You choose how to handle this yourself. Just like the NAME constant idiom for Mediators and Proxies, if you only ever need one instance of a core then you can do just what you've described. But if you need multiple instances, (as do Prattler and Modularity) then you need to make the multitonKey unique.

-=Cliff>
« Last Edit: March 10, 2010, 01:37:36 by puremvc » Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #2 on: March 09, 2010, 12:09:43 »

Ok, thanks!  At this point, I am trying to keep different cores straight and so it has helped to give them a unique class name as opposed to ApplicationFacade and/or have their getInstance() return a specific and unique instance without worrying about keys.  But then the question becomes, why do I need MultiCore to do this?  Why not just use the regular framework? 

In other words, what would stop me from having multiple singleton ApplicationFacades in one project?  Again, the caveat being that each Facade class would have a one-to-one relationship with their Application or Module.

I haven't dug into the multicore source files enough yet to answer this question myself...
...or maybe I should just try doing it that way and see what happens...
Sorry if this is (yet another) stupid question.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: March 10, 2010, 01:39:17 »

what would stop me from having multiple singleton ApplicationFacades in one project?
The fact that the Facade is a Singleton. In multicore, it is a Multiton, (a map of Singletons).

-=Cliff>
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #4 on: March 11, 2010, 07:15:04 »

Right...
What I was thinking was that each class could potentially have its own getInstance() returning its own class defined instance property.  But that won't work when the other actors, which are ignorant of the sub-class's unique/special getInstance() method just call the static getInstance() method on the superclass (Facade).

I can call AFacade.getInstance(), BFacade.getInstance() all I want, the framework is calling Facade.getInstance().  Likewise, the Facade class does not instantiate Model and View as new instances but rather accesses them as Singletons.  If a Model and View were instantiated for each Facade instance, then I might actually be able to make what I proposed above work.

So yeah, I basically just forgot what being a Singleton meant when I started asking myself what a being a Multiton meant.

whew! that was dumb.
Logged
Pages: [1]
Print